From minecraft2048 at gmail.com Tue May 1 05:16:28 2018 From: minecraft2048 at gmail.com (Ignatius Rivaldi) Date: Tue, 1 May 2018 15:16:28 +1000 Subject: fl2k_* have libusb: error [op_dev_mem_alloc] alloc dev mem failed errno 12 Message-ID: Hi, I've compiled osmo-fl2k with libusb-1.0.22-1 and this happens when I tried to start fl2k_test: feanor at silmaril ~> fl2k_test -s 162e6 Using 6 zero-copy buffers libusb: error [op_dev_mem_alloc] alloc dev mem failed errno 12 Failed to allocate zero-copy buffer for transfer 4 Reporting PPM error measurement every 10 seconds... Press ^C after a few minutes. real sample rate: 15372775 current PPM: -905106 cumulative PPM: -905106 then when I try to connect red and ground output to oscilloscope, there is no output at all, even if I use fl2k_fm From steve at steve-m.de Tue May 1 09:51:14 2018 From: steve at steve-m.de (Steve Markgraf) Date: Tue, 1 May 2018 11:51:14 +0200 Subject: fl2k_* have libusb: error [op_dev_mem_alloc] alloc dev mem failed errno 12 In-Reply-To: References: Message-ID: <3cd3b886-afb0-cf95-65b4-5b8c4fd6494f@steve-m.de> Hi Ignatius, On 01.05.2018 07:16, Ignatius Rivaldi wrote: > feanor at silmaril ~> fl2k_test -s 162e6 > Using 6 zero-copy buffers > libusb: error [op_dev_mem_alloc] alloc dev mem failed errno 12 > Failed to allocate zero-copy buffer for transfer 4 The lib will try to allocate contiguous device memory from the Kernel through libusb, this may fail for various reasons (not enough contiguous DMA-capable memory because CONFIG_CMA_SIZE_MBYTES is set too low etc). However, osmo-fl2k falls back to buffers in userspace should the zero-copy buffer allocation fail, so no need to worry here. > real sample rate: 15372775 current PPM: -905106 cumulative PPM: -905106 >From the output above it seems that your FL2000 device is connected to a USB 2.0 port, so it only can achieve 14-15 MS/s. You need a USB 3.0 port for higher rates. > then when I try to connect red and ground output to oscilloscope, > there is no output at all, even if I use fl2k_fm Yes, if the sample rate the host can supply does not match the PLL frequency of the FL2000, the line buffer in the chip will underrun and then there is no output anymore until re-initializing the device. Regards, Steve From azerty_lr at hotmail.com Tue May 1 12:03:48 2018 From: azerty_lr at hotmail.com (azerty lr) Date: Tue, 1 May 2018 12:03:48 +0000 Subject: osmo-fl2k baseband to carrier Message-ID: Hello, First thank you for this FL2000 hack, it's very nice! I tried to make an FM & AM transmitter with it and GNU Radio. It's working fine if I save to a file and then use fl2k_file to transmit the data but with the tcp server and fl2k_tcp, my computer is not fast enough to sample in real time at 100 MHz. I also tried with a 35 Mhz sampling rate but it's not real time. Here is the diagram I used. Is there a possibility to avoid sampling at a very fast rate if the data bandwidth is small to do the baseband to carrier shift? [cid:0115622e-668a-46ae-8e49-07a3a7aba391] Thank you, Best regards, Jean-Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fm_tx.PNG Type: image/png Size: 46178 bytes Desc: fm_tx.PNG URL: From mueller at kit.edu Wed May 2 10:42:42 2018 From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=) Date: Wed, 2 May 2018 10:42:42 +0000 Subject: osmo-fl2k baseband to carrier In-Reply-To: References: Message-ID: <1525257762.28278.55.camel@kit.edu> Well, as a VGA adapter, the FL2000 doesn't come with any mixer. So, all you can do is use images, since the DAC also lacks a proper reconstruction filter. You get mathematical repetitions at every multiple of the sampling rate ? "undersampling" is the the term you want to read up on. Best regards, Marcus On Tue, 2018-05-01 at 12:03 +0000, azerty lr wrote: > Hello, > > First thank you for this FL2000 hack, it's very nice! > > I tried to make an FM & AM transmitter with it and GNU Radio. It's working fine if I save to a file and then use fl2k_file to transmit the data but with the tcp server and fl2k_tcp, my computer is not fast enough to sample in real time at 100 MHz. I also tried with a 35 Mhz sampling rate but it's not real time. Here is the diagram I used. > > Is there a possibility to avoid sampling at a very fast rate if the data bandwidth is small to do the baseband to carrier shift? > > > Thank you, > Best regards, > Jean-Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6582 bytes Desc: not available URL: From mueller at kit.edu Wed May 2 19:29:54 2018 From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=) Date: Wed, 2 May 2018 19:29:54 +0000 Subject: osmo-fl2k baseband to carrier In-Reply-To: References: ,<1525257762.28278.55.camel@kit.edu> Message-ID: <1525289392.20452.2.camel@kit.edu> Hi Jean-Paul, no, as the warning in the GRC console should have told you: NEVER use a throttle in a hardware flow graph. It doesn't do anything, but will lead to continuity problems. You can't define a signal at 35 MHz with a 35 MHz real-valued sampling rate ? you'd need twice of that, at least; but since your sampling rate also defines the distance between spectral images, more careful choice of sampling rate is necessary for succesfull undersampling. Best regards, Marcus On Wed, 2018-05-02 at 19:10 +0000, azerty lr wrote: > Hello, > > Ok so the Gnu Radio diagram that I did is correct? I tried a carrier > frequency of 1 Mhz with a sampling rate of 31 Mhz of I should have > got a signal at 30Mhz but it was not working very well. I needed a > carrier of at least 2 Mhz to got a signal. > > Best regards, > Jean-Paul > De : M?ller, Marcus (CEL) > Envoy? : mercredi 2 mai 2018 12:42 > ? : azerty_lr at hotmail.com; osmocom-sdr at lists.osmocom.org > Objet : Re: osmo-fl2k baseband to carrier > > Well, as a VGA adapter, the FL2000 doesn't come with any mixer. > So, all you can do is use images, since the DAC also lacks a proper > reconstruction filter. You get mathematical repetitions at every > multiple of the sampling rate ? "undersampling" is the the term you > want to read up on. > > Best regards, > Marcus > > On Tue, 2018-05-01 at 12:03 +0000, azerty lr wrote: > > Hello, > > > > First thank you for this FL2000 hack, it's very nice! > > > > I tried to make an FM & AM transmitter with it and GNU Radio. It's > working fine if I save to a file and then use fl2k_file to transmit > the data but with the tcp server and fl2k_tcp, my computer is not > fast enough to sample in real time at 100 MHz. I also tried with a 35 > Mhz sampling rate but it's not real time. Here is the diagram I used. > > > > Is there a possibility to avoid sampling at a very fast rate if the > data bandwidth is small to do the baseband to carrier shift? > > > > > > Thank you, > > Best regards, > > Jean-Paul From azerty_lr at hotmail.com Wed May 2 19:10:48 2018 From: azerty_lr at hotmail.com (azerty lr) Date: Wed, 2 May 2018 19:10:48 +0000 Subject: osmo-fl2k baseband to carrier In-Reply-To: <1525257762.28278.55.camel@kit.edu> References: , <1525257762.28278.55.camel@kit.edu> Message-ID: Hello, Ok so the Gnu Radio diagram that I did is correct? I tried a carrier frequency of 1 Mhz with a sampling rate of 31 Mhz of I should have got a signal at 30Mhz but it was not working very well. I needed a carrier of at least 2 Mhz to got a signal. Best regards, Jean-Paul ________________________________ De : M?ller, Marcus (CEL) Envoy? : mercredi 2 mai 2018 12:42 ? : azerty_lr at hotmail.com; osmocom-sdr at lists.osmocom.org Objet : Re: osmo-fl2k baseband to carrier Well, as a VGA adapter, the FL2000 doesn't come with any mixer. So, all you can do is use images, since the DAC also lacks a proper reconstruction filter. You get mathematical repetitions at every multiple of the sampling rate ? "undersampling" is the the term you want to read up on. Best regards, Marcus On Tue, 2018-05-01 at 12:03 +0000, azerty lr wrote: > Hello, > > First thank you for this FL2000 hack, it's very nice! > > I tried to make an FM & AM transmitter with it and GNU Radio. It's working fine if I save to a file and then use fl2k_file to transmit the data but with the tcp server and fl2k_tcp, my computer is not fast enough to sample in real time at 100 MHz. I also tried with a 35 Mhz sampling rate but it's not real time. Here is the diagram I used. > > Is there a possibility to avoid sampling at a very fast rate if the data bandwidth is small to do the baseband to carrier shift? > > > Thank you, > Best regards, > Jean-Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.janovsky at gmail.com Tue May 8 11:05:05 2018 From: anton.janovsky at gmail.com (Anton Janovsky) Date: Tue, 08 May 2018 11:05:05 +0000 Subject: fl2k_tcp stream format. Message-ID: Hi I would like to use the fl2k_tcp utility to transmit remotely but are not sure what is tje format of stream to send to this utility. 1) Do I send an IQ stream or audio stream? 2) is there some example to generate stream for this and format explenation? 3) how do you define carrier freq? 73 ' Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Tue May 8 19:55:25 2018 From: steve at steve-m.de (Steve Markgraf) Date: Tue, 8 May 2018 21:55:25 +0200 Subject: fl2k_tcp stream format. In-Reply-To: References: Message-ID: <2d20cf7a-be45-713b-5b21-e3b373ed23f7@steve-m.de> Hi Anton, On 08.05.2018 13:05, Anton Janovsky wrote: > 1) Do I send an IQ stream or audio stream? It uses raw, signed 8 bit samples, just like fl2k_file. There no further processing performed in fl2k_tcp, you need to supply the samples you want to output with the DAC at the full sample rate set with the -s command line option. You can take a look here if you want to see how to generate the samples: https://github.com/steve-m/fl2k-examples Regards, Steve From maccody at att.net Thu May 10 03:44:21 2018 From: maccody at att.net (Mac A. Cody) Date: Wed, 9 May 2018 22:44:21 -0500 Subject: Discerning FL2K devices with LDOs versus switching regulators Message-ID: <044e5d32-6881-10fa-84ad-35049835ca91@att.net> Greetings, In Steve Markgraf's slide presentation (http://people.osmocom.org/steve-m/fl2k_slides/osmo-fl2k.html), do slides 16 and 17 imply that some FL2K devices have LDO regulators while other using switching regulators?? Obviously, the FL2K devices that have LDO regulators are preferred, due to fewer spurious RF emissions.? How can one determine which FL2K devices have LDOs?? Can an FL2K device be reworked to use LDO regulators? Thanks, Mac From mueller at kit.edu Thu May 10 08:48:14 2018 From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=) Date: Thu, 10 May 2018 08:48:14 +0000 Subject: Discerning FL2K devices with LDOs versus switching regulators In-Reply-To: <044e5d32-6881-10fa-84ad-35049835ca91@att.net> References: <044e5d32-6881-10fa-84ad-35049835ca91@att.net> Message-ID: <1525942092.3372.54.camel@kit.edu> Hi Mac, so first of all: any spur is only a problem if it ends up in your signal. Since we're clearly talking about devices that you can't use for operation with an antenna withou very much filtering: check whether you actually get a problem first. To be completely honest, the whole LDO vs. SMPS discussion often bares technical background, as you'll find SMPS in high-end radio receiver devices just as well. It's all about /designing/ your thing to be low noise, not about the "use an LDO instead of a switcher". Now, Steve has offered nice figures about the spurs there, so these might actually be linked to the switcher. However, the method seems to be to first measure, then link cause to it; not the other way around. I'd argue that the device with the many spurs that, actually do look like one rectangular wave modulated another rectangular wave, was simply badly designed, probably with underdimensioned means of eliminating cross-talk between the two switchers (no idea how they relate). What confuses me is that these spurs roughly fall into a 3 MHz grid ? and that's usually a bit on the high end for switching frequencies. Another device with a switcher *might* be nicely filtered and work perfectly well. I agree, adding a switching regulater definitely adds a source of noise, but please don't assume that cheaply designed LDO systems are superior in signal quality?; there's modern switch mode supplies that actually use spread-spectrum methods to spread out the energy they leak onto many frequencies?, and others that you can synchronize e.g. to sampling clocks so that noise at least aligns and can be filtered out more easily. The point I'm trying to make is that if these spurs are a problem to you (and I can heartily to figure on slide 17 worrying you), then you'll want to have spur measurements at different sampling rates at exactly your USB bus ? in the end, the noise of a SMPS very much depends on how hard it is at work, and a stable input supply and high output current might be nicer than a dropping input and a current draw so small that forces the SMPS into discontinuous current mode. Regarding spotting: ------------------- Switch mode supplies generally can be found by looking for (large-ish) inductors close to (large-ish) diodes, typically close to either a converter IC or in higher-current applications close to a (large-ish) discrete transistor. Do an image search for "SMD power inductor", and you'll see how these tend to look like. Regarding remedies: ------------------- Filters, filters, filters?! You need to select the right Nyquist zone, anyway. So, pick a sampling rate range that works out for that; shifting your signal in digital domain so that it ends up where you want it after being shifted by the sample clock N times allows you to have some leeway there. Then, use whatever remaining degrees of freedom you have to pick a rate that is at a supply spur ? and filter that out. Whether this is an option at all of course depends on the RF bandwidth you need. Replacing the power supply on-board: I'm willing to say "it's possible", but I'd also say "at a time investment higher than simply buying a handful of candidates and simply sticking with one that works". Supplies typically have to be electrically well-coupled to the ground and supply lines, so if you externalize these, you'd replace the original output stage of the on-board SMPS with larger capacitors, but these typically have worse RF interference suppression properties, so you'd add smaller capacitors, but now you have a system with capacitors of different sizes and internal resistances and inherently some inductive characteristics of whatever connects the external supply to these connectors ? you can certainly simply build that, and it's not that unlikely it'd work, especially if you overdimension everything a bit, but I wouldn't know how to predictably make a "first trial works" device. Note that switch mode ICs for these voltages and currents aren't necessarily solder-friendly? . Rule of thumb: The smaller the package, the higher the switching frequency? ? and as noted above, 3 MHz would be at the higher end of the spectrum of switching frequencies?, but that's likely because higher switching frequency also makes the necessary inductance smaller, and hence, the inductor cheaper. What I would do =============== Compare a handful of dongles. Because: a) They're cheap, and time is sparse, b) can't be that bad to have spare ones lying around, for operation away from the spurs, or to give to friends who want to try that, or to honestly resell as tested to work with osmo-fl2k but replaced with a lower-noise one, c) to verify hypotheses on how to fix things, without risking to fry one of the "good ones", and c) if you can figure out how to improving the best one, maybe it becomes easy to improve the others, too. Maybe it's easier to observe an improvement in the ones that are bad. Go and measure. That means that I'd both add appropriate output filters for both the Nyquist zone I want, and measure after that (e.g. using an RTL dongle, whose spurs I at least know), as well as trying to figure out where exactly the spurs come from ? are they really on the signal lines, or are they radiated into my measurement by the shield conductor of the VGA port? When I probe around with an oscilloscope, on which lines do I see exactly these frequencies I observed? Then, improve and adapt. If things are actually radiated by the board, proper shielding might be the simplest method to improve the situation. Else, go for easy things like soldering another (better, as in lower ESR, higher capacity?) capacitor onto the decoupling capacitors or output smoothing caps on-board? first. Best regards, Marcus ======================================================================= ? You can underdampen these LDOs, just as well, or underdimension them: linear supplies tend to be cheaper than SMPS for small loads, so the fact that some manufacturers use SMPSes might point out that you'd need a relatively beefy and fast LDO and thus expensive LDO to reliably supply the current needed, and there's plenty that you can mess up when you're designing an LDO system at the edge of cost efficiency ? Though that doesn't sound too desirable here ? Imagine Ballmer going "developers!" on you here. ? In highly integrated electronics, ICs with 6 pads in a package of total size ~ 1 mm ? 1.3 mm would be typical if you just need a small step-down from 1.8 V to 1.2 V efficiently. ? Because the higher the frequency, the less charge transfered per cycle, the lower the switched current, the smaller the switching transistor. ? Please don't really infer that this means you get a chip scale package ? these VGA dongles were built with cost, not size, as primary target, as you can see from the sparsely populated simple PCBs; you don't use a high-end phone-building assembly line to build 5 ? VGA dongles, so you don't use <0.05 mm tolerance in placement parts. ? Maybe don't take it this far: https://twitter.com/LaF0rge/status/892872883164336128 On Wed, 2018-05-09 at 22:44 -0500, Mac A. Cody wrote: > Greetings, > > In Steve Markgraf's slide presentation > (http://people.osmocom.org/steve-m/fl2k_slides/osmo-fl2k.html), > do slides 16 and 17 imply that some FL2K devices have LDO regulators > while other > using switching regulators? Obviously, the FL2K devices that have > LDO > regulators > are preferred, due to fewer spurious RF emissions. How can one > determine which > FL2K devices have LDOs? Can an FL2K device be reworked to use LDO > regulators? > > Thanks, > > Mac -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6582 bytes Desc: not available URL: From maccody at att.net Fri May 11 01:13:14 2018 From: maccody at att.net (Mac A. Cody) Date: Thu, 10 May 2018 20:13:14 -0500 Subject: Discerning FL2K devices with LDOs versus switching regulators In-Reply-To: <1525942092.3372.54.camel@kit.edu> References: <044e5d32-6881-10fa-84ad-35049835ca91@att.net> <1525942092.3372.54.camel@kit.edu> Message-ID: Marcus, Thank you for your prompt, detailed, informative, and (even) entertaining reply.? Many of the things you mentioned I am already aware of, but this information is definitely valuable as a reminder and for those unaware of all of the issues.? You put in far more time into your reply than I would have ever hoped for and it is greatly appreciated! I'm looking at using the FL2K for amateur radio HF band applications.? I want to employ a sampling rate of 120 Msps and a low-pass filter with a roll-off just above 30 MHz.? I'm considering using an Odroid XU4 as an embedded processor, as it has significant processing capability and it has two USB 3.0 hosts.? Of course, a suitably enhanced RTL-SDR device would be used for the SDR receiver component.? Alternatively, an SDRPlay RSP1A could be used. Regards, Mac On 05/10/2018 03:48 AM, M?ller, Marcus (CEL) wrote: > Hi Mac, > > so first of all: any spur is only a problem if it ends up in your > signal. Since we're clearly talking about devices that you can't use > for operation with an antenna withou very much filtering: check whether > you actually get a problem first. To be completely honest, the whole > LDO vs. SMPS discussion often bares technical background, as you'll > find SMPS in high-end radio receiver devices just as well. It's all > about /designing/ your thing to be low noise, not about the "use an LDO > instead of a switcher". > > Now, Steve has offered nice figures about the spurs there, so these > might actually be linked to the switcher. However, the method seems to > be to first measure, then link cause to it; not the other way around. > I'd argue that the device with the many spurs that, actually do look > like one rectangular wave modulated another rectangular wave, was > simply badly designed, probably with underdimensioned means of > eliminating cross-talk between the two switchers (no idea how they > relate). What confuses me is that these spurs roughly fall into a 3 MHz > grid ? and that's usually a bit on the high end for switching > frequencies. > > Another device with a switcher *might* be nicely filtered and work > perfectly well. I agree, adding a switching regulater definitely adds a > source of noise, but please don't assume that cheaply designed LDO > systems are superior in signal quality?; there's modern switch mode > supplies that actually use spread-spectrum methods to spread out the > energy they leak onto many frequencies?, and others that you can > synchronize e.g. to sampling clocks so that noise at least aligns and > can be filtered out more easily. > > The point I'm trying to make is that if these spurs are a problem to > you (and I can heartily to figure on slide 17 worrying you), then > you'll want to have spur measurements at different sampling rates at > exactly your USB bus ? in the end, the noise of a SMPS very much > depends on how hard it is at work, and a stable input supply and high > output current might be nicer than a dropping input and a current draw > so small that forces the SMPS into discontinuous current mode. > > Regarding spotting: > ------------------- > > Switch mode supplies generally can be found by looking for (large-ish) > inductors close to (large-ish) diodes, typically close to either a > converter IC or in higher-current applications close to a (large-ish) > discrete transistor. Do an image search for "SMD power inductor", and > you'll see how these tend to look like. > > > Regarding remedies: > ------------------- > > Filters, filters, filters?! > You need to select the right Nyquist zone, anyway. So, pick a sampling > rate range that works out for that; shifting your signal in digital > domain so that it ends up where you want it after being shifted by the > sample clock N times allows you to have some leeway there. Then, use > whatever remaining degrees of freedom you have to pick a rate that is > at a supply spur ? and filter that out. Whether this is an option at > all of course depends on the RF bandwidth you need. > > Replacing the power supply on-board: > I'm willing to say "it's possible", but I'd also say "at a time > investment higher than simply buying a handful of candidates and simply > sticking with one that works". > Supplies typically have to be electrically well-coupled to the ground > and supply lines, so if you externalize these, you'd replace the > original output stage of the on-board SMPS with larger capacitors, but > these typically have worse RF interference suppression properties, so > you'd add smaller capacitors, but now you have a system with capacitors > of different sizes and internal resistances and inherently some > inductive characteristics of whatever connects the external supply to > these connectors ? you can certainly simply build that, and it's not > that unlikely it'd work, especially if you overdimension everything a > bit, but I wouldn't know how to predictably make a "first trial works" > device. > Note that switch mode ICs for these voltages and currents aren't > necessarily solder-friendly? . Rule of thumb: The smaller the package, > the higher the switching frequency? ? and as noted above, 3 MHz would > be at the higher end of the spectrum of switching frequencies?, but > that's likely because higher switching frequency also makes the > necessary inductance smaller, and hence, the inductor cheaper. > > What I would do > =============== > > Compare a handful of dongles. Because: > a) They're cheap, and time is sparse, > b) can't be that bad to have spare ones lying around, for operation > away from the spurs, or to give to friends who want to try that, or to > honestly resell as tested to work with osmo-fl2k but replaced with a > lower-noise one, > c) to verify hypotheses on how to fix things, without risking to fry > one of the "good ones", and > c) if you can figure out how to improving the best one, maybe it > becomes easy to improve the others, too. Maybe it's easier to observe > an improvement in the ones that are bad. > > Go and measure. That means that I'd both add appropriate output filters > for both the Nyquist zone I want, and measure after that (e.g. using an > RTL dongle, whose spurs I at least know), as well as trying to figure > out where exactly the spurs come from ? are they really on the signal > lines, or are they radiated into my measurement by the shield conductor > of the VGA port? When I probe around with an oscilloscope, on which > lines do I see exactly these frequencies I observed? > > Then, improve and adapt. If things are actually radiated by the board, > proper shielding might be the simplest method to improve the situation. > Else, go for easy things like soldering another (better, as in lower > ESR, higher capacity?) capacitor onto the decoupling capacitors or > output smoothing caps on-board? first. > > Best regards, > Marcus > > ======================================================================= > > ? You can underdampen these LDOs, just as well, or underdimension them: > linear supplies tend to be cheaper than SMPS for small loads, so the > fact that some manufacturers use SMPSes might point out that you'd need > a relatively beefy and fast LDO and thus expensive LDO to reliably > supply the current needed, and there's plenty that you can mess up when > you're designing an LDO system at the edge of cost efficiency > > ? Though that doesn't sound too desirable here > > ? Imagine Ballmer going "developers!" on you here. > > ? In highly integrated electronics, ICs with 6 pads in a package of > total size ~ 1 mm ? 1.3 mm would be typical if you just need a small > step-down from 1.8 V to 1.2 V efficiently. > > ? Because the higher the frequency, the less charge transfered per > cycle, the lower the switched current, the smaller the switching > transistor. > > ? Please don't really infer that this means you get a chip scale > package ? these VGA dongles were built with cost, not size, as primary > target, as you can see from the sparsely populated simple PCBs; you > don't use a high-end phone-building assembly line to build 5 ? VGA > dongles, so you don't use <0.05 mm tolerance in placement parts. > > ? Maybe don't take it this far: > https://twitter.com/LaF0rge/status/892872883164336128 > > On Wed, 2018-05-09 at 22:44 -0500, Mac A. Cody wrote: >> Greetings, >> >> In Steve Markgraf's slide presentation >> (http://people.osmocom.org/steve-m/fl2k_slides/osmo-fl2k.html), >> do slides 16 and 17 imply that some FL2K devices have LDO regulators >> while other >> using switching regulators? Obviously, the FL2K devices that have >> LDO >> regulators >> are preferred, due to fewer spurious RF emissions. How can one >> determine which >> FL2K devices have LDOs? Can an FL2K device be reworked to use LDO >> regulators? >> >> Thanks, >> >> Mac From maccody at att.net Sat May 12 03:34:56 2018 From: maccody at att.net (Mac A. Cody) Date: Fri, 11 May 2018 22:34:56 -0500 Subject: Discerning FL2K devices with LDOs versus switching regulators In-Reply-To: <1525942092.3372.54.camel@kit.edu> References: <044e5d32-6881-10fa-84ad-35049835ca91@att.net> <1525942092.3372.54.camel@kit.edu> Message-ID: Marcus, Thank you for your prompt, detailed, informative, and (even) entertaining reply.? Many of the things you mentioned I am already aware of, but thisinformation is definitely valuable as a reminder and for those unaware of all of the issues.? You put in far more time into your reply than I would have ever hoped for and it is greatly appreciated! I'm looking at using the FL2K for amateur radio HF band applications.? I want to employ a sampling rate of 120 Msps and a low-pass filter with a roll-off just above 30 MHz.? I'm considering using an Odroid XU4 as an embedded processor, as it has significant processing capability and it has two USB 3.0 hosts.? Of course, a suitably enhanced RTL-SDR device would be used for the SDR receiver component.? Alternatively, an SDRPlay RSP1A could be used. Regards, Mac On 05/10/2018 03:48 AM, M?ller, Marcus (CEL) wrote: > Hi Mac, > > so first of all: any spur is only a problem if it ends up in your > signal. Since we're clearly talking about devices that you can't use > for operation with an antenna withou very much filtering: check whether > you actually get a problem first. To be completely honest, the whole > LDO vs. SMPS discussion often bares technical background, as you'll > find SMPS in high-end radio receiver devices just as well. It's all > about /designing/ your thing to be low noise, not about the "use an LDO > instead of a switcher". > > Now, Steve has offered nice figures about the spurs there, so these > might actually be linked to the switcher. However, the method seems to > be to first measure, then link cause to it; not the other way around. > I'd argue that the device with the many spurs that, actually do look > like one rectangular wave modulated another rectangular wave, was > simply badly designed, probably with underdimensioned means of > eliminating cross-talk between the two switchers (no idea how they > relate). What confuses me is that these spurs roughly fall into a 3 MHz > grid ? and that's usually a bit on the high end for switching > frequencies. > > Another device with a switcher *might* be nicely filtered and work > perfectly well. I agree, adding a switching regulater definitely adds a > source of noise, but please don't assume that cheaply designed LDO > systems are superior in signal quality?; there's modern switch mode > supplies that actually use spread-spectrum methods to spread out the > energy they leak onto many frequencies?, and others that you can > synchronize e.g. to sampling clocks so that noise at least aligns and > can be filtered out more easily. > > The point I'm trying to make is that if these spurs are a problem to > you (and I can heartily to figure on slide 17 worrying you), then > you'll want to have spur measurements at different sampling rates at > exactly your USB bus ? in the end, the noise of a SMPS very much > depends on how hard it is at work, and a stable input supply and high > output current might be nicer than a dropping input and a current draw > so small that forces the SMPS into discontinuous current mode. > > Regarding spotting: > ------------------- > > Switch mode supplies generally can be found by looking for (large-ish) > inductors close to (large-ish) diodes, typically close to either a > converter IC or in higher-current applications close to a (large-ish) > discrete transistor. Do an image search for "SMD power inductor", and > you'll see how these tend to look like. > > > Regarding remedies: > ------------------- > > Filters, filters, filters?! > You need to select the right Nyquist zone, anyway. So, pick a sampling > rate range that works out for that; shifting your signal in digital > domain so that it ends up where you want it after being shifted by the > sample clock N times allows you to have some leeway there. Then, use > whatever remaining degrees of freedom you have to pick a rate that is > at a supply spur ? and filter that out. Whether this is an option at > all of course depends on the RF bandwidth you need. > > Replacing the power supply on-board: > I'm willing to say "it's possible", but I'd also say "at a time > investment higher than simply buying a handful of candidates and simply > sticking with one that works". > Supplies typically have to be electrically well-coupled to the ground > and supply lines, so if you externalize these, you'd replace the > original output stage of the on-board SMPS with larger capacitors, but > these typically have worse RF interference suppression properties, so > you'd add smaller capacitors, but now you have a system with capacitors > of different sizes and internal resistances and inherently some > inductive characteristics of whatever connects the external supply to > these connectors ? you can certainly simply build that, and it's not > that unlikely it'd work, especially if you overdimension everything a > bit, but I wouldn't know how to predictably make a "first trial works" > device. > Note that switch mode ICs for these voltages and currents aren't > necessarily solder-friendly? . Rule of thumb: The smaller the package, > the higher the switching frequency? ? and as noted above, 3 MHz would > be at the higher end of the spectrum of switching frequencies?, but > that's likely because higher switching frequency also makes the > necessary inductance smaller, and hence, the inductor cheaper. > > What I would do > =============== > > Compare a handful of dongles. Because: > a) They're cheap, and time is sparse, > b) can't be that bad to have spare ones lying around, for operation > away from the spurs, or to give to friends who want to try that, or to > honestly resell as tested to work with osmo-fl2k but replaced with a > lower-noise one, > c) to verify hypotheses on how to fix things, without risking to fry > one of the "good ones", and > c) if you can figure out how to improving the best one, maybe it > becomes easy to improve the others, too. Maybe it's easier to observe > an improvement in the ones that are bad. > > Go and measure. That means that I'd both add appropriate output filters > for both the Nyquist zone I want, and measure after that (e.g. using an > RTL dongle, whose spurs I at least know), as well as trying to figure > out where exactly the spurs come from ? are they really on the signal > lines, or are they radiated into my measurement by the shield conductor > of the VGA port? When I probe around with an oscilloscope, on which > lines do I see exactly these frequencies I observed? > > Then, improve and adapt. If things are actually radiated by the board, > proper shielding might be the simplest method to improve the situation. > Else, go for easy things like soldering another (better, as in lower > ESR, higher capacity?) capacitor onto the decoupling capacitors or > output smoothing caps on-board? first. > > Best regards, > Marcus > > ======================================================================= > > ? You can underdampen these LDOs, just as well, or underdimension them: > linear supplies tend to be cheaper than SMPS for small loads, so the > fact that some manufacturers use SMPSes might point out that you'd need > a relatively beefy and fast LDO and thus expensive LDO to reliably > supply the current needed, and there's plenty that you can mess up when > you're designing an LDO system at the edge of cost efficiency > > ? Though that doesn't sound too desirable here > > ? Imagine Ballmer going "developers!" on you here. > > ? In highly integrated electronics, ICs with 6 pads in a package of > total size ~ 1 mm ? 1.3 mm would be typical if you just need a small > step-down from 1.8 V to 1.2 V efficiently. > > ? Because the higher the frequency, the less charge transfered per > cycle, the lower the switched current, the smaller the switching > transistor. > > ? Please don't really infer that this means you get a chip scale > package ? these VGA dongles were built with cost, not size, as primary > target, as you can see from the sparsely populated simple PCBs; you > don't use a high-end phone-building assembly line to build 5 ? VGA > dongles, so you don't use <0.05 mm tolerance in placement parts. > > ? Maybe don't take it this far: > https://twitter.com/LaF0rge/status/892872883164336128 > > On Wed, 2018-05-09 at 22:44 -0500, Mac A. Cody wrote: >> Greetings, >> >> In Steve Markgraf's slide presentation >> (http://people.osmocom.org/steve-m/fl2k_slides/osmo-fl2k.html), >> do slides 16 and 17 imply that some FL2K devices have LDO regulators >> while other >> using switching regulators? Obviously, the FL2K devices that have >> LDO >> regulators >> are preferred, due to fewer spurious RF emissions. How can one >> determine which >> FL2K devices have LDOs? Can an FL2K device be reworked to use LDO >> regulators? >> >> Thanks, >> >> Mac From zaitcev at kotori.zaitcev.us Sun May 13 20:19:31 2018 From: zaitcev at kotori.zaitcev.us (Pete Zaitcev) Date: Sun, 13 May 2018 15:19:31 -0500 Subject: [PATCH] Fix rtl_adsb hanging upon a signal in Fedora 27 Message-ID: <20180513151931.66f217c0@lembas.zaitcev.lan> This code stayed unchanged for many years, but for some reason rtl_adsb started hanging upon exit: *b66116a5164b69281eacc42ae950; ^CSignal caught, exiting! <------ hangs here forever Examining it with gdb reveals that the demod thread waits peacefully on the condition variable, which we're trying to destroy. Either the signals killed all threads before, or condition variables were possible to destroy while other threads still waited on them. The easiest fix appears to be just cancel the demod thread and wait for it to exit before proceeding for the door. --- src/rtl_adsb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/rtl_adsb.c b/src/rtl_adsb.c index 07fdd2a..9087de4 100644 --- a/src/rtl_adsb.c +++ b/src/rtl_adsb.c @@ -492,6 +492,8 @@ int main(int argc, char **argv) else { fprintf(stderr, "\nLibrary error %d, exiting...\n", r);} rtlsdr_cancel_async(dev); + pthread_cancel(demod_thread); + pthread_join(demod_thread, NULL); pthread_cond_destroy(&ready); pthread_mutex_destroy(&ready_m); From caj380 at gmail.com Mon May 14 16:34:23 2018 From: caj380 at gmail.com (Chase Johnson) Date: Mon, 14 May 2018 12:34:23 -0400 Subject: Transmitting Digital ATSC TV signals using Osmo-fl2k Message-ID: Hi all, I am new to Software Defined Radio and I was wondering if it was possible to broadcast a Digital ATSC TV channel using Osmo-fl2k ( https://osmocom.org/projects/osmo-fl2k/wiki/Osmo-fl2k). I am in need of a device that can do this for my work and didn't want to pay $1000+ for the equipment designed for this purpose. Thank you for your help, Chase Johnson -- Sent from an Apple Newton MessagePad 100 https://goo.gl/v82H1C -------------- next part -------------- An HTML attachment was scrubbed... URL: From acebrianjuan at gmail.com Tue May 15 13:42:10 2018 From: acebrianjuan at gmail.com (=?UTF-8?B?w4FsdmFybyBDZWJyacOhbiBKdWFu?=) Date: Tue, 15 May 2018 15:42:10 +0200 Subject: Blacklist files in /etc/modprobe.d/ Message-ID: Hi everyone, Do osmo-sdr or gr-osmosdr place blacklist files in /etc/modprobe.d/ when they are installed? I am asking this because there I have found the files "hackrf-blacklist.conf" and "rtl-sdr-blacklist.conf" and I would like to know where they came from. Thank you. Regards, ?lvaro -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at kit.edu Tue May 15 13:54:17 2018 From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=) Date: Tue, 15 May 2018 13:54:17 +0000 Subject: Blacklist files in /etc/modprobe.d/ In-Reply-To: References: Message-ID: <1526392457.28278.163.camel@kit.edu> Hi ?lvaro, gr-osmosdr doesn't contain any of these drivers nor their blacklist files themselves ? it's but a "shim" to plug these drivers into GNU Radio. So, you'll have to look into libhackrf and librtlsdr, respectively. Notice that if you've installed these via your linux distro package manager, then the maintainer of the respective package usually is the one that defines which files go where. Best regards, Marcus On Tue, 2018-05-15 at 15:42 +0200, ?lvaro Cebri?n Juan wrote: > Hi everyone, > > Do osmo-sdr or gr-osmosdr place blacklist files in /etc/modprobe.d/ when they are installed? > I am asking this because there I have found the files "hackrf-blacklist.conf" and "rtl-sdr-blacklist.conf" and I would like to know where they came from. > > Thank you. > Regards, > > ?lvaro -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6582 bytes Desc: not available URL: From abcd at bitmessage.ch Wed May 16 11:18:51 2018 From: abcd at bitmessage.ch (R B) Date: Wed, 16 May 2018 13:18:51 +0200 Subject: fl2k - low samplerate/ no rf-output Message-ID: <9AD843F2-0709-4296-AAB1-60E81BA20E9E@bitmessage.ch> Hello Gang ;) i have some troubles, properly "misusing" my vga-adapter. the samplerate while testing with fl2k_test is pretty low (~50MS/s) and i am not sure if this is some hardware issue or. RF-Output isn?t detectable either. i am using a lenovo thinkpad x1 hybrid (1294). any help is appreciated. $ fl2k_test -s 162e6 Reporting PPM error measurement every 10 seconds... Press ^C after a few minutes. real sample rate: 52862885 current PPM: -673686 cumulative PPM: -673686 real sample rate: 52973828 current PPM: -673001 cumulative PPM: -673342 real sample rate: 53014975 current PPM: -672747 cumulative PPM: -673143 real sample rate: 52979890 current PPM: -672964 cumulative PPM: -673098 ^CSignal caught, exiting! $ fl2k_test -s 51e6 Reporting PPM error measurement every 10 seconds... Press ^C after a few minutes. real sample rate: 51037366 current PPM: 733 cumulative PPM: 733 real sample rate: 51031823 current PPM: 624 cumulative PPM: 678 real sample rate: 51025418 current PPM: 498 cumulative PPM: 617 real sample rate: 51023557 current PPM: 462 cumulative PPM: 578 real sample rate: 51019821 current PPM: 389 cumulative PPM: 540 real sample rate: 51017641 current PPM: 346 cumulative PPM: 507 ^CSignal caught, exiting! $ sudo lspci -vv|grep "USB 3" -A 200 0f:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: Lenovo uPD720200 USB 3.0 Host Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- From marcus.mueller at ettus.com Sun May 20 08:06:23 2018 From: marcus.mueller at ettus.com (=?ISO-8859-1?Q?Marcus_M=FCller?=) Date: Sun, 20 May 2018 10:06:23 +0200 Subject: fl2k - low samplerate/ no rf-output In-Reply-To: <9AD843F2-0709-4296-AAB1-60E81BA20E9E@bitmessage.ch> References: <9AD843F2-0709-4296-AAB1-60E81BA20E9E@bitmessage.ch> Message-ID: <2D524192-480A-4EB3-AFEC-9C94B677B4A0@ettus.com> Have you tried getting output with one of the other tools? Best regards, Marcus On 16 May 2018 13:18:51 GMT+02:00, R B wrote: >Hello Gang ;) > >i have some troubles, properly "misusing" my vga-adapter. >the samplerate while testing with fl2k_test is pretty low (~50MS/s) and >i am not sure if this is some hardware issue or. RF-Output isn?t >detectable either. i am using a lenovo thinkpad x1 hybrid (1294). >any help is appreciated. > > >$ fl2k_test -s 162e6 >Reporting PPM error measurement every 10 seconds... >Press ^C after a few minutes. >real sample rate: 52862885 current PPM: -673686 cumulative PPM: -673686 >real sample rate: 52973828 current PPM: -673001 cumulative PPM: -673342 >real sample rate: 53014975 current PPM: -672747 cumulative PPM: -673143 >real sample rate: 52979890 current PPM: -672964 cumulative PPM: -673098 >^CSignal caught, exiting! > >$ fl2k_test -s 51e6 >Reporting PPM error measurement every 10 seconds... >Press ^C after a few minutes. >real sample rate: 51037366 current PPM: 733 cumulative PPM: 733 >real sample rate: 51031823 current PPM: 624 cumulative PPM: 678 >real sample rate: 51025418 current PPM: 498 cumulative PPM: 617 >real sample rate: 51023557 current PPM: 462 cumulative PPM: 578 >real sample rate: 51019821 current PPM: 389 cumulative PPM: 540 >real sample rate: 51017641 current PPM: 346 cumulative PPM: 507 >^CSignal caught, exiting! > >$ sudo lspci -vv|grep "USB 3" -A 200 >0f:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host >Controller (rev 04) (prog-if 30 [XHCI]) >Subsystem: Lenovo uPD720200 USB 3.0 Host Controller >Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >Stepping- SERR- FastB2B- DisINTx+ >Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0, Cache Line Size: 64 bytes >Interrupt: pin A routed to IRQ 18 >Region 0: Memory at f1400000 (64-bit, non-prefetchable) [size=8K] >Capabilities: [50] Power Management version 3 >Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA >PME(D0+,D1-,D2-,D3hot+,D3cold+) >Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- >Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+ >Address: 0000000000000000 Data: 0000 >Capabilities: [90] MSI-X: Enable+ Count=8 Masked- >Vector table: BAR=0 offset=00001000 >PBA: BAR=0 offset=00001080 >Capabilities: [a0] Express (v2) Endpoint, MSI 00 >DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 >unlimited > ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- >DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- > RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ > MaxPayload 128 bytes, MaxReadReq 512 bytes >DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend- >LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency >L0s <4us, L1 unlimited > ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- >LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+ > ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- >LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- >BWMgmt- ABWMgmt- >DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR+, OBFF Not >Supported >DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF >Disabled >LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- >Transmit Margin: Normal Operating Range, EnterModifiedCompliance- >ComplianceSOS- > Compliance De-emphasis: -6dB >LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, >EqualizationPhase1- > EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- >Capabilities: [100 v1] Advanced Error Reporting >UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- >MalfTLP- ECRC- UnsupReq- ACSViol- >UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- >MalfTLP- ECRC- UnsupReq- ACSViol- >UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ >MalfTLP+ ECRC- UnsupReq- ACSViol- >CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- >CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ >AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn- >Capabilities: [140 v1] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff >Capabilities: [150 v1] Latency Tolerance Reporting >Max snoop latency: 0ns >Max no snoop latency: 0ns >Kernel driver in use: xhci_hcd > > >$ lsusb >Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching >Hub >Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >Bus 004 Device 002: ID 1d5c:2000 >Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub >Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching >Hub >Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > >$ usb-devices |grep "Bus=04 Lev=01" -A 100 >T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=5000 MxCh= 0 >D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 >P: Vendor=1d5c ProdID=2000 Rev=02.00 >C: #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=496mA >I: If#= 0 Alt= 0 #EPs= 0 Cls=10() Sub=00 Prot=00 Driver=(none) >I: If#= 1 Alt= 0 #EPs= 2 Cls=10() Sub=02 Prot=00 Driver=(none) >I: If#= 2 Alt= 0 #EPs= 1 Cls=10() Sub=02 Prot=00 Driver=(none) > >$ lsmod|grep usb > >$ lsmod|grep xhci > > >thank you and cheers >robin -- This was written on my cellular phone. whilst an impressive piece of engineering, this might not be the perfect device to write emails on - please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ted.yapo at gmail.com Sun May 20 16:22:27 2018 From: ted.yapo at gmail.com (Ted Yapo) Date: Sun, 20 May 2018 12:22:27 -0400 Subject: fl2k file does not accept "-" as filename to read from stdin Message-ID: $ fl2k_file fl2k_file, a sample player for FL2K VGA dongles Usage: [-d device_index (default: 0)] [-r repeat file (default: 1)] [-s samplerate (default: 100 MS/s)] filename (use '-' to read from stdin) $ fl2k_file -s 8192000 - Failed to open - I'm perfectly willing to pitch in and fix this. How do you prefer to receive contributions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Sun May 20 17:27:54 2018 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 20 May 2018 19:27:54 +0200 Subject: fl2k file does not accept "-" as filename to read from stdin In-Reply-To: References: Message-ID: Hi, > I'm perfectly willing to pitch in and fix this. How do you prefer to > receive contributions? Patch posted on the mailing list, preferrably using git-send-email so the format is standardized. Cheers, Sylvain From matthias at mpb.li Sun May 20 17:54:05 2018 From: matthias at mpb.li (=?UTF-8?Q?Matthias_Br=c3=a4ndli?=) Date: Sun, 20 May 2018 19:54:05 +0200 Subject: fl2k file does not accept "-" as filename to read from stdin In-Reply-To: References: Message-ID: <4b536103-ac3f-4c9c-1112-907f0b37e64b@mpb.li> Dear all, On 20/05/18 19:27, Sylvain Munaut wrote: > Patch posted on the mailing list, preferrably using git-send-email so > the format is standardized. I don't have git-send-email set up, enclosed is a patch that adds interleaved I/Q -> Red/Green output. I hope this is of interest to you. Cheers mpb -------------- next part -------------- A non-text attachment was scrubbed... Name: interleaved_rg.patch Type: text/x-patch Size: 5166 bytes Desc: not available URL: From ted.yapo at gmail.com Mon May 21 05:36:34 2018 From: ted.yapo at gmail.com (Ted Yapo) Date: Mon, 21 May 2018 01:36:34 -0400 Subject: fl2k file does not accept "-" as filename to read from stdin In-Reply-To: References: Message-ID: --- src/fl2k_file.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/src/fl2k_file.c b/src/fl2k_file.c index 1d3697d..a3df0f0 100644 --- a/src/fl2k_file.c +++ b/src/fl2k_file.c @@ -145,11 +145,15 @@ int main(int argc, char **argv) if (dev_index < 0) exit(1); - file = fopen(filename, "rb"); - if (!file) { - fprintf(stderr, "Failed to open %s\n", filename); - goto out; - } + if (!strcmp(filename, "-")){ + file = stdin; + } else { + file = fopen(filename, "rb"); + if (!file) { + fprintf(stderr, "Failed to open %s\n", filename); + goto out; + } + } txbuf = malloc(FL2K_BUF_LEN); if (!txbuf) { -- 2.7.4 On Sun, May 20, 2018 at 1:27 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > I'm perfectly willing to pitch in and fix this. How do you prefer to > > receive contributions? > > Patch posted on the mailing list, preferrably using git-send-email so > the format is standardized. > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From babarbuttgrt at yahoo.com Mon May 21 15:09:24 2018 From: babarbuttgrt at yahoo.com (Babar Ali) Date: Mon, 21 May 2018 15:09:24 +0000 (UTC) Subject: Osmo-trx compile error References: <169737036.3615010.1526915364181.ref@mail.yahoo.com> Message-ID: <169737036.3615010.1526915364181@mail.yahoo.com> I?received?following error while compling osmo-trx on rasbian, i have already build libosmocore-0-11-0 from source and?installed but despite this still unable to compile osmo-trx, any?one can help to resolve the issue! configure: error: Package requirements (libosmocore >= 0.11.0) were not met: Requested ?libosmocore >= 0.11.0? but version of Osmocom Core Library is UNKNOWN Consider adjusting the PKG_CONFIG_PATH environment variable if you?installed software in a non-standard prefix.? I have already build following components on Rasbian from source successfully LimeSuite?SoapySDR?SoapyUHD?libosmocore-0.11.0/ libosmocore-0.96.0 Regards Babar -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed May 23 17:37:12 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 23 May 2018 19:37:12 +0200 Subject: Osmo-trx compile error In-Reply-To: <169737036.3615010.1526915364181@mail.yahoo.com> References: <169737036.3615010.1526915364181.ref@mail.yahoo.com> <169737036.3615010.1526915364181@mail.yahoo.com> Message-ID: <20180523173712.GW3639@nataraja> The osmocom-sdr mailing list is not the apropriate place for this. Please see https://osmocom.org/projects/osmotrx/wiki/OsmoTRX#Mailing-List -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From sdr_is_cool at riseup.net Wed May 23 14:18:58 2018 From: sdr_is_cool at riseup.net (SDR is cool) Date: Wed, 23 May 2018 14:18:58 +0000 Subject: [osmo-fl2k] Code issues/warnings report Message-ID: <9ccf3fbe74b50078e26bad0a2fbd07c9@riseup.net> Hi everybody, Thank you for developing osmo-fl2k. Just wanted to report some relevant code issues/warnings I've found in osmo-fl2k's codebase: hope you'll find it useful. All the issues reported below are based upon the source code as seen in commit 16b102efcdae6c33b1761e4f2da8c507eed03bb4 (osmo-fl2k's git repo current HEAD). - libosmo-fl2k.c:213 Implicit cast of expression '(pll_clock * mult) / (uint32_t) div' from 'uint32_t' type to 'double' type (perform explicit cast to avoid the loss of the fractional part. Is it intentional?). - libosmo-fl2k.c:216 Implicit cast of expression '(uint32_t) offset * frac' from 'uint32_t' type to 'double' type (perform explicit cast to avoid integer overflow). - libosmo-fl2k.c:250 Absolute value function 'fabsf' given an argument of type 'double' but has parameter of type 'float' which may cause truncation of value (use function 'fabs' instead). - libosmo-fl2k.c:252 Absolute value function 'fabsf' given an argument of type 'double' but has parameter of type 'float' which may cause truncation of value (use function 'fabs' instead). - libosmo-fl2k.c:262 Absolute value function 'fabsf' given an argument of type 'double' but has parameter of type 'float' which may cause truncation of value (use function 'fabs' instead). - libosmo-fl2k.c:263 Incorrect 'fprintf' format for argument 'target_freq' (use '%lu' format specifier and add explicit cast like: '(unsigned long)target_freq' or use 'PRIu32' macro from 'inttypes.h'). - libosmo-fl2k.c:458 Useless if (expression 'dev' is always true). - libosmo-fl2k.c:577 There might be dereferencing of a potential null pointer 'dev->xfer' (malloc call at may return NULL: line 574). - libosmo-fl2k.c:580 A potential null pointer is given to 'memset' function (malloc call may return NULL: line 579). - libosmo-fl2k.c:583 A potential null pointer is given to 'memset' function (malloc call may return NULL: line 582). - libosmo-fl2k.c:586 Incorrect 'fprintf' format for argument 'dev->xfer_buf_num' (use '%lu' format specifier and add explicit cast like: '(unsigned long)dev->xfer_buf_num' or use 'PRIu32' macro from 'inttypes.h'). - libosmo-fl2k.c:593 Incorrect 'fprintf' format for argument 'i' (use '%u' format specifier). - libosmo-fl2k.c:650 Incorrect 'fprintf' format for argument 'i' (use '%u' format specifier). - libosmo-fl2k.c:856 Incorrect 'fprintf' format for argument 'dev->underflow_cnt - underflows' (use '%lu' format specifier and add explicit cast like: '(unsigned long)(dev->underflow_cnt - underflows)' or use 'PRIu32' macro from 'inttypes.h'). - fl2k_file.c:98 Incorrect 'fprintf' format for argument 'repeat_cnt' (use '%lu' format specifier and add explicit cast like: '(unsigned long)repeat_cnt' or use 'PRIu32' macro from 'inttypes.h'). - fl2k_file.c:169 The 'r' variable is assigned values twice successively (missing return code check after first assignment?). - fl2k_fm.c:570 The 'r' variable is assigned values twice successively (missing return code check after first assignment?). - fl2k_tcp.c:193 The 'r' variable is assigned values twice successively (missing return code check after first assignment?). - fl2k_test.c:259 Incorrect 'fprintf' format for argument 'dev_index' (use '%lu' format specifier and add explicit cast like: '(unsigned long)dev_index' or use 'PRIu32' macro from 'inttypes.h'). - fl2k_test.c:278 Integer overflow (attempt to store value 255 in a char type variable (which may be signed: range [-128, 127]): redefine 'buffer' variable as 'signed char' type to fix the issue). - fl2k_test.c:284 The 'r' variable is assigned values twice successively (missing return code check after first assignment?). - fl2k_test.c:301 Useless if (expression 'do_exit' is always true). Regards, SDR_is_cool From steve at steve-m.de Wed May 23 21:16:51 2018 From: steve at steve-m.de (Steve Markgraf) Date: Wed, 23 May 2018 23:16:51 +0200 Subject: fl2k file does not accept "-" as filename to read from stdin In-Reply-To: References: Message-ID: <375c85fa-b66e-fead-63b7-ddbd1bd4d2f5@steve-m.de> Hi Ted, thanks for reporting this, I've just comitted a fix. I've just copied it from fl2k_fm, which already has this functionality including a quirk for Windows. Regards, Steve From steve at steve-m.de Wed May 23 21:27:14 2018 From: steve at steve-m.de (Steve Markgraf) Date: Wed, 23 May 2018 23:27:14 +0200 Subject: [PATCH] Fix rtl_adsb hanging upon a signal in Fedora 27 In-Reply-To: <20180513151931.66f217c0@lembas.zaitcev.lan> References: <20180513151931.66f217c0@lembas.zaitcev.lan> Message-ID: <7afb33ee-989d-0532-184d-537f45407c4f@steve-m.de> Hi Pete, thanks for the patch, merged it. Regards, Steve From admin at rtl-sdr.com Thu May 24 04:31:55 2018 From: admin at rtl-sdr.com (Carl Laufer) Date: Thu, 24 May 2018 16:31:55 +1200 Subject: R820T Loop Through Message-ID: Is there any reason for this to be turned on during normal operation of the RTL-SDR? Turning it off seems to reduce current usage by 10 to 20 mA. To turn it off set reg 0x05 bit 7 to 1. Seems to turned be on by default. Haven't seen any effects from turning it off. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.montefusco at gmail.com Thu May 24 14:36:26 2018 From: andrea.montefusco at gmail.com (andrea montefusco) Date: Thu, 24 May 2018 16:36:26 +0200 Subject: gr-osmodr patches Message-ID: Hi gr-osmosdr maintainer, can I respectfully ask if the several patches to the gr-osmosdr library, sent in the past months on this list, will have a chance to be considered in the near future? ?Many thanks in advance *am* -- Andrea Montefusco IW0HDV ------------------------------------------ As my old boss, an Apollo veteran, would often remind us ?It?s good to be smart, but it?s better to be lucky.? Wayne Hale, Space Shuttle Flight Director -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Thu May 24 22:18:42 2018 From: steve at steve-m.de (Steve Markgraf) Date: Fri, 25 May 2018 00:18:42 +0200 Subject: R820T Loop Through In-Reply-To: References: Message-ID: <36d50d2b-5729-b38f-d0e0-5e6cafe60689@steve-m.de> Hi Carl, On 24.05.2018 06:31, Carl Laufer wrote: > Is there any reason for this to be turned on during normal operation of > the RTL-SDR? No, not really, I'm not aware of any sticks making use of the loop-through output. > Turning it off seems to reduce current usage by 10 to 20 mA. To turn it > off set reg 0x05 bit 7 to 1. Seems to turned be on by default. Haven't > seen any effects from turning it off. Good point, I've just committed a patch that turns it off. Regards, Steve From chibill110 at gmail.com Thu May 24 23:36:11 2018 From: chibill110 at gmail.com (Bill Gaylord) Date: Thu, 24 May 2018 18:36:11 -0500 Subject: RTLSDR Dongle Getting very hot even with out use. Message-ID: <8299A25D-7631-450D-8627-9EC0BD6A9A0E@gmail.com> I am having this problem with all of my dongles (from multiple sources) and was wondering if it could be some sort of problem with it not getting closed properly, In all cases the chip that gets hot is the actual SDR not the tuner. But I don?t understand why it is heating up when the dongle is not in use and is just plugged in. Or is this just some weird problem with the dongles. Sincerely, William From mueller at kit.edu Fri May 25 12:06:43 2018 From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=) Date: Fri, 25 May 2018 12:06:43 +0000 Subject: RTLSDR Dongle Getting very hot even with out use. In-Reply-To: <8299A25D-7631-450D-8627-9EC0BD6A9A0E@gmail.com> References: <8299A25D-7631-450D-8627-9EC0BD6A9A0E@gmail.com> Message-ID: <1527250003.22463.79.camel@kit.edu> Since it gets hot even if you just plugged it in and didn't use it once (if I read your email correctly), and since there's literally no driver here that takes automated control of the dongle and sends it any commands: That's a hardware issue. The RTL28.. contains linear regulators, and these probably are running continuosly. Best regards, Marcus On Thu, 2018-05-24 at 18:36 -0500, Bill Gaylord wrote: > I am having this problem with all of my dongles (from multiple sources) and was wondering if it could be some sort of problem with it not getting closed properly, > > In all cases the chip that gets hot is the actual SDR not the tuner. But I don?t understand why it is heating up when the dongle is not in use and is just plugged in. > > Or is this just some weird problem with the dongles. > > > Sincerely, > William -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6582 bytes Desc: not available URL: From osmocom at lains.me Sat May 26 18:47:59 2018 From: osmocom at lains.me (Filipe =?iso-8859-1?b?TGHtbnM=?=) Date: Sat, 26 May 2018 19:47:59 +0100 Subject: Is it possible to provide a compressed file for every git tag? Message-ID: <1527360479.4374.1@smtp.migadu.com> Hi, I am packaging some of your software for Arch Linux. For that, I need to fetch the source tree I want to build. The problem is that there's no need to fetch the whole git repository to build a specific tag. As a solution, I propose that compressed files from every tag would be available, like GitHub releases. Please let me know if this is something you would consider doing. Thanks, Filipe La?ns (FFY00) https://github.com/FFY00 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2 Sent via Migadu.com, world's easiest email hosting -------------- next part -------------- An HTML attachment was scrubbed... URL: From chibill110 at gmail.com Sat May 26 19:07:56 2018 From: chibill110 at gmail.com (Bill Gaylord) Date: Sat, 26 May 2018 15:07:56 -0400 Subject: Is it possible to provide a compressed file for every git tag? In-Reply-To: <1527360479.4374.1@smtp.migadu.com> References: <1527360479.4374.1@smtp.migadu.com> Message-ID: You could use the git option to not download the whole history. (Can?t remember it?s name.) William. > On May 26, 2018, at 2:47 PM, Filipe La?ns wrote: > > Hi, > > I am packaging some of your software for Arch Linux. For that, I need to fetch the source tree I want to build. The problem is that there's no need to fetch the whole git repository to build a specific tag. As a solution, I propose that compressed files from every tag would be available, like GitHub releases. > Please let me know if this is something you would consider doing. > > Thanks, > Filipe La?ns (FFY00) > https://github.com/FFY00 > 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2 > Sent via Migadu.com, world's easiest email hosting -------------- next part -------------- An HTML attachment was scrubbed... URL: From staticfloat at gmail.com Sat May 26 19:30:38 2018 From: staticfloat at gmail.com (Elliot Saba) Date: Sat, 26 May 2018 12:30:38 -0700 Subject: Is it possible to provide a compressed file for every git tag? In-Reply-To: References: <1527360479.4374.1@smtp.migadu.com> Message-ID: It's called a shallow clone. You use `git clone --depth 1 `. If you need to "unshallow" the clone afterwards to get all the history, you can use `git pull --unshallow` -------------- next part -------------- An HTML attachment was scrubbed... URL: From chibill110 at gmail.com Sat May 26 19:07:56 2018 From: chibill110 at gmail.com (Bill Gaylord) Date: Sat, 26 May 2018 15:07:56 -0400 Subject: Is it possible to provide a compressed file for every git tag? In-Reply-To: <1527360479.4374.1@smtp.migadu.com> References: <1527360479.4374.1@smtp.migadu.com> Message-ID: You could use the git option to not download the whole history. (Can?t remember it?s name.) William. > On May 26, 2018, at 2:47 PM, Filipe La?ns wrote: > > Hi, > > I am packaging some of your software for Arch Linux. For that, I need to fetch the source tree I want to build. The problem is that there's no need to fetch the whole git repository to build a specific tag. As a solution, I propose that compressed files from every tag would be available, like GitHub releases. > Please let me know if this is something you would consider doing. > > Thanks, > Filipe La?ns (FFY00) > https://github.com/FFY00 > 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2 > Sent via Migadu.com, world's easiest email hosting -------------- next part -------------- An HTML attachment was scrubbed... URL: From loay.razek at gmail.com Fri May 25 09:29:20 2018 From: loay.razek at gmail.com (loay abdelrazek) Date: Fri, 25 May 2018 05:29:20 -0400 Subject: RTL-SDR Continuous Operation Message-ID: Hello, would like to know, what is the average time that an RTL-SDR (R820T2) can run nonstop without affecting its internals The use case, is to sniff GSM packets noting that sniffing will take several intervals during the day, and the experiment should only run for 1 day , thus what could be the appropriate interval thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.mueller at ettus.com Sun May 27 08:09:52 2018 From: marcus.mueller at ettus.com (Marcus =?ISO-8859-1?Q?M=FCller?=) Date: Sun, 27 May 2018 10:09:52 +0200 Subject: Is it possible to provide a compressed file for every git tag? In-Reply-To: <1527360479.4374.1@smtp.migadu.com> References: <1527360479.4374.1@smtp.migadu.com> Message-ID: <1527408592.12069.4.camel@ettus.com> Hi Filipe, please be a bit careful not to inadvertedly DDOS the OSMOCOM cgit server in case a lot of people want to build your recipe, but: https://git.osmocom.org/osmo-fl2k/snapshot/osmo-fl2k-%{git_commit}.tar. gz Best regards, Marcus On Sat, 2018-05-26 at 19:47 +0100, Filipe La?ns wrote: > Hi, > > I am packaging some of your software for Arch Linux. For that, I need > to fetch the source tree I want to build. The problem is that there's > no need to fetch the whole git repository to build a specific tag. As > a solution, I propose that compressed files from every tag would be > available, like GitHub releases. > Please let me know if this is something you would consider doing. > > Thanks, > Filipe La?ns (FFY00) > https://github.com/FFY00 > 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2 > Sent via Migadu.com, world's easiest email hosting From jim.dallas at gmail.com Tue May 29 15:40:58 2018 From: jim.dallas at gmail.com (James Dallas) Date: Tue, 29 May 2018 10:40:58 -0500 Subject: Request for help with MxL608 tuner driver (Tzumi MagicTV etc) Message-ID: Hi everyone, There has been a considerable discussion in the past couple of days about a device called the Tzumi MagicTV. This is an Atheros-chipset OpenWRT device connected to an RTL2832P, which seems to be used as a bridge/DAC for a MaxLinear MxL608 tuner and a Panasonic ATSC demodulator. The device is sold at Wal-Mart stores for $13, and is intended to allow the user to view OTA broadcasts using a WiFi connection to the device, which functions as an access point by default. There also seems to be an Eardatek Tevemo device which is similar. >From tear-down inspection as well as poking around the file system, some uses have concluded that the device could be used as a software defined radio with some software modifications (for example replacing the default ATSC server software with rtl_tcp). However, librtlsdr does not currently support the MxL608 tuner, and right now rtl_tcp (when placed on the openWRT device) defaults to direct sampling mode. There is a general sense in these discussion groups that MaxLinear's source code could be ported to work with librtlsdr, but someone would have to make that happen. I am sending this message to the group, to reach out with a humble request/suggest/beg that someone(s) please help us out by doing the following: 1. Sanity-check the claims being made; if what is being discussed is not workable, it would be of benefit for us to be told so. 2. Start work on forking librtlsdr and porting the MxL608 driver over (if possible/practical); 3. Coordinate with the broader community to beta-test and refine // help spread the knowledge so that the community can maintain/improve the fork and perhaps submit a pull-request in the future. Please let me know if I can help you help us by procuring/shipping a couple of hardware units for development purposes. I understand that asking people to do volunteer work can be presumptuous/annoying. All I can say in my defense is that there are already at least a few dozen people who would be really happy and appreciative if this came to fruition, and "one does not get what one does not ask for." Moreover, adding MxL608 support to librtlsdr might help broaden the hobby to include a whole bunch of other devices; MaxLinear tuners seem to be used a lot with set-top gear. Thank you very much, James "Gwen" Dallas, AD5NL Reddit user: texasyojimbo Phone: 1-713-254-4175 P.S. here are the existing discussion threads for reference: 1. RTL-SDR.com blog: https://www.rtl-sdr.com/tzumi-magictv-wifi-tv-tuner-device-contains-an-rtl-sdr-openwrt-board-and-battery-for-only-13/ 2. Reddit RTLSDR group: https://www.reddit.com/r/RTLSDR/comments/8mlbps/tzumi_magictv_is_an_openwrt_board_rtlsdr/ P.P.S here is a link to the existing MxL608 driver source code: https://github.com/avlogic/AVL6862/tree/master/2.10.7/tuner/MxL608 and data sheet: https://datasheet.lcsc.com/szlcsc/MXL608-AG-T_C141783.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjvonblack at riseup.net Tue May 29 15:36:43 2018 From: jjvonblack at riseup.net (JJ) Date: Tue, 29 May 2018 17:36:43 +0200 Subject: fl2k - low samplerate/ no rf-output In-Reply-To: <9AD843F2-0709-4296-AAB1-60E81BA20E9E@bitmessage.ch> Message-ID: <4fc8cd7451959c41654b81f1f38e1dd2@riseup.net> Hi everyone, Thanks for the osmo-fl2k gift! Unfortunately it seems I'm experiencing the same issue as the one reported by the original poster. I've compiled osmo-fl2k from source[1] and run it on Ubuntu 16.04 x86_64 both on a notebook and a desktop PC (with USB 3 ports) without noticing any detectable RF activity[2]. Is there any way to debug/tackle the issue? Is it VGA adapter dependent? Here are more information: dmesg: usb 2-1: new high-speed USB device number 7 using xhci_hcd usb 2-1: New USB device found, idVendor=1d5c, idProduct=2000 usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 $ timeout 120s fl2k_test -s 162e6 Reporting PPM error measurement every 10 seconds... Press ^C after a few minutes. Signal caught, exiting! User cancel, exiting... real sample rate: 15018460 current PPM: -907293 cumulative PPM: -907293 real sample rate: 15018133 current PPM: -907295 cumulative PPM: -907294 real sample rate: 15018646 current PPM: -907292 cumulative PPM: -907294 real sample rate: 15018427 current PPM: -907294 cumulative PPM: -907294 real sample rate: 15018391 current PPM: -907294 cumulative PPM: -907294 real sample rate: 15018312 current PPM: -907294 cumulative PPM: -907294 real sample rate: 15018434 current PPM: -907294 cumulative PPM: -907294 real sample rate: 15018472 current PPM: -907293 cumulative PPM: -907294 real sample rate: 15018498 current PPM: -907293 cumulative PPM: -907294 real sample rate: 15018216 current PPM: -907295 cumulative PPM: -907294 real sample rate: 15018345 current PPM: -907294 cumulative PPM: -907294 $ timeout 120s fl2k_test -s 100e6 Reporting PPM error measurement every 10 seconds... Press ^C after a few minutes. Signal caught, exiting! User cancel, exiting... real sample rate: 15018468 current PPM: -849815 cumulative PPM: -849815 real sample rate: 15018365 current PPM: -849816 cumulative PPM: -849816 real sample rate: 15018384 current PPM: -849816 cumulative PPM: -849816 real sample rate: 15018349 current PPM: -849817 cumulative PPM: -849816 real sample rate: 15018350 current PPM: -849816 cumulative PPM: -849816 real sample rate: 15018447 current PPM: -849816 cumulative PPM: -849816 real sample rate: 15018135 current PPM: -849819 cumulative PPM: -849816 real sample rate: 15018684 current PPM: -849813 cumulative PPM: -849816 real sample rate: 15018346 current PPM: -849817 cumulative PPM: -849816 real sample rate: 15018375 current PPM: -849816 cumulative PPM: -849816 real sample rate: 15018317 current PPM: -849817 cumulative PPM: -849816 $ timeout 120s fl2k_test -s 50e6 Reporting PPM error measurement every 10 seconds... Press ^C after a few minutes. Signal caught, exiting! User cancel, exiting... real sample rate: 15018520 current PPM: -699630 cumulative PPM: -699630 real sample rate: 15018385 current PPM: -699632 cumulative PPM: -699631 real sample rate: 15018272 current PPM: -699635 cumulative PPM: -699632 real sample rate: 15018553 current PPM: -699629 cumulative PPM: -699631 real sample rate: 15018344 current PPM: -699633 cumulative PPM: -699632 real sample rate: 15018424 current PPM: -699632 cumulative PPM: -699632 real sample rate: 15018236 current PPM: -699635 cumulative PPM: -699632 real sample rate: 15018548 current PPM: -699629 cumulative PPM: -699632 real sample rate: 15018338 current PPM: -699633 cumulative PPM: -699632 real sample rate: 15018347 current PPM: -699633 cumulative PPM: -699632 real sample rate: 15018426 current PPM: -699631 cumulative PPM: -699632 $ timeout 120s fl2k_test -s 15e6 Reporting PPM error measurement every 10 seconds... Press ^C after a few minutes. Signal caught, exiting! User cancel, exiting... real sample rate: 15000126 current PPM: 8 cumulative PPM: 8 real sample rate: 15000152 current PPM: 10 cumulative PPM: 9 real sample rate: 15000230 current PPM: 15 cumulative PPM: 11 real sample rate: 15000151 current PPM: 10 cumulative PPM: 11 real sample rate: 15000273 current PPM: 18 cumulative PPM: 13 real sample rate: 14999886 current PPM: -8 cumulative PPM: 9 real sample rate: 15000499 current PPM: 33 cumulative PPM: 13 real sample rate: 15000221 current PPM: 15 cumulative PPM: 13 real sample rate: 15000182 current PPM: 12 cumulative PPM: 13 real sample rate: 15000234 current PPM: 16 cumulative PPM: 13 real sample rate: 15000160 current PPM: 11 cumulative PPM: 13 $ sudo lsusb -d 1d5c:2000 -vv Bus 002 Device 004: ID 1d5c:2000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x1d5c idProduct 0x2000 bcdDevice 2.00 iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 269 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 98mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 3 bFunctionClass 14 Video bFunctionSubClass 1 Video Control bFunctionProtocol 3 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 16 bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 16 bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 04 21 00 01 ** UNRECOGNIZED: 06 25 01 00 00 00 ** UNRECOGNIZED: 06 25 02 00 00 00 ** UNRECOGNIZED: 0a 22 01 00 05 00 02 00 00 00 ** UNRECOGNIZED: 06 25 01 00 00 00 ** UNRECOGNIZED: 0a 22 02 00 10 00 14 00 0d 00 ** UNRECOGNIZED: 0a 23 03 00 0d 00 05 00 00 00 ** UNRECOGNIZED: 06 25 02 00 01 00 ** UNRECOGNIZED: 10 26 01 00 00 00 00 00 64 00 00 00 01 00 00 00 ** UNRECOGNIZED: 0a 24 01 00 14 00 00 00 00 00 ** UNRECOGNIZED: 06 25 03 00 01 00 ** UNRECOGNIZED: 0a 24 02 00 02 00 00 00 00 00 ** UNRECOGNIZED: 06 25 03 00 01 00 ** UNRECOGNIZED: 06 25 0c 00 00 00 ** UNRECOGNIZED: 06 25 09 00 02 00 ** UNRECOGNIZED: 06 25 0b 00 01 00 ** UNRECOGNIZED: 14 27 00 00 01 00 3c 00 01 00 02 00 03 00 00 00 00 00 02 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 16 bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 16 bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 25 Transfer Type Isochronous Synch Type Adaptive Usage Type Feedback wMaxPacketSize 0x0004 1x 4 bytes bInterval 7 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x1400 3x 1024 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 16 bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 22 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000c Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 2 Lowest fully-functional device speed is High Speed (480Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 20 micro seconds Device Status: 0x0000 (Bus Powered) $ sudo lspci -s 00:14.0 -vv 00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04) (prog-if 30 [XHCI]) Subsystem: Dell 8 Series USB xHCI HC Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- References: <3cd3b886-afb0-cf95-65b4-5b8c4fd6494f@steve-m.de> Message-ID: <743a2e6e-b925-e742-6fa6-5391c1d85a2b@yahoo.com> > not enough contiguous DMA-capable memory because CONFIG_CMA_SIZE_MBYTES is set too low etc I have the same error message running a standard ubuntu kernel 4.15.0-21-generic with 16 GB RAM. I'm not familiar with setting the right kernel options. My config file for the kernel just shows: CONFIG_CMA=y # CONFIG_CMA_DEBUG is not set # CONFIG_CMA_DEBUGFS is not set CONFIG_CMA_AREAS=7 I haven't been able to receive a FM signal yet. My output from the fl2k_test shows: sudo fl2k_test -s 162e6 Allocating 6 zero-copy buffers libusb: error [op_dev_mem_alloc] alloc dev mem failed errno 12 Failed to allocate zero-copy buffer for transfer 4 Falling back to buffers in userspace Reporting PPM error measurement every 10 seconds... Press ^C after a few minutes. real sample rate: 113962068 current PPM: -296530 cumulative PPM: -296530 real sample rate: 113975309 current PPM: -296449 cumulative PPM: -296489 real sample rate: 114139355 current PPM: -295436 cumulative PPM: -296136 Do I need to change my kernel settings or will the device simply won't work? From 246tnt at gmail.com Thu May 31 07:45:38 2018 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 31 May 2018 09:45:38 +0200 Subject: fl2k - low samplerate/ no rf-output In-Reply-To: <4fc8cd7451959c41654b81f1f38e1dd2@riseup.net> References: <9AD843F2-0709-4296-AAB1-60E81BA20E9E@bitmessage.ch> <4fc8cd7451959c41654b81f1f38e1dd2@riseup.net> Message-ID: > dmesg: > usb 2-1: new high-speed USB device number 7 using xhci_hcd > usb 2-1: New USB device found, idVendor=1d5c, idProduct=2000 > usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 There is your problem .... it should say "Super Speed" for a USB3 device. There has been several reports that some low quality devices just are broken out-of-the-box ... Some with the super speed wires badly soldered or at the wrong place. Cheers, Sylvain From phip at devtal.de Thu May 31 15:50:02 2018 From: phip at devtal.de (Philipp Psurek) Date: Thu, 31 May 2018 17:50:02 +0200 Subject: fl2k_* have libusb: error [op_dev_mem_alloc] alloc dev mem failed errno 12 In-Reply-To: <743a2e6e-b925-e742-6fa6-5391c1d85a2b@yahoo.com> References: <3cd3b886-afb0-cf95-65b4-5b8c4fd6494f@steve-m.de> <743a2e6e-b925-e742-6fa6-5391c1d85a2b@yahoo.com> Message-ID: <1527781802.5077.3.camel@devtal.de> Am Mittwoch, den 30.05.2018, 17:57 +0200 schrieb Hannes Wagner: > sudo fl2k_test -s 162e6 > [?] > real sample rate: 113962068 current PPM: -296530 cumulative PPM: -296530 ^^^^^^^ Try to decrease your samplerate. 162 MHz is to much. I have to use about 140 MHz on ASMedia/AMD. See: http://osmocom.org/projects/osmo-fl2k/wiki#USB-Host-Controller-comparison -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: