From holger at freyther.de Thu Feb 4 07:12:19 2016 From: holger at freyther.de (Holger Freyther) Date: Thu, 4 Feb 2016 08:12:19 +0100 Subject: Moving from trac to a single redmine Message-ID: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> Hi guys, I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now. Tickets: Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either: * not import tickets * only import from one project * deal with changing ticket numbers In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number? Wiki: We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this? kind regards holger From laforge at gnumonks.org Fri Feb 5 16:10:54 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 5 Feb 2016 17:10:54 +0100 Subject: Moving from trac to a single redmine In-Reply-To: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> Message-ID: <20160205161054.GE10932@nataraja> Hi Holger, On Thu, Feb 04, 2016 at 08:12:19AM +0100, Holger Freyther wrote: > I think some of us would like to move to redmine and start using > public tickets more frequently. So in case we move there are some > topics to be discussed and I would like to start with a couple of them > right now. Thanks for getting the public discussion about this started. To give some more background to the mailing list: * The trac installations at osmocom.org are pretty much underused/dormant. The only part that's used is the Wiki. * Osmocom started when a single project (OpenBSC) got a sister project (OsmocomBB) and has grown into many projects. Running a single trac instance for each project on a separate dns hostname is overkill. Also, as code is shifted around between libraries and programs, we'd appreciate some flexibility. * at sysmocom internally we have successfully used redmine for dozens of different projects. The project hierarchy can be changed as needed on the fly, and issues can relate to issues of other projects, shifted from project to project, etc. * Quite a bit of the work we do at sysmocom on the Osmocom software should have the issue tracker for bugs and features in the public, but as our internal redmine is so much easier than the public trac setup, we kept using the internal redmine. So my plan moving forward is to migrate all Osmocom projects (initially those related to GSM) to a public redmine, and then keep all issues updated there. This would give more visibility into the work we're doing, such as the EDGE PCU, the 3G NITB + SGSN, the HNB-GW, etc. > Redmine has a global linear sequence of ticket numbers. If we move > from many tracs to a single redmine we can either: > > * not import tickets > * only import from one project > * deal with changing ticket numbers I think not importing tickets or dealing wih changing numbers is the way to go. > In terms of installations the GMR trac is broken in regard to tickets, > there are some for SDR that are probably not being fixed anytime soon, > baseband might be relevant and OpenBSC is unlikely to be relevant. I > don't think we have ever used ticket reference in OpenBSC commit > messages so in terms of OpenBSC having changing ticket numbers would > not be a big deal. E.g. we could add a custom field with the old trac > number? If there is automatic import/conversion available, I'd prefer to import the OsmocomBB, SIMtrace, (non-spam) Security and OpenBSC tickets, even though most of them are probably stale and outdated for years. They're still part of the history. Changing the numbers doesn't matter, as we don't refer to them. > We have external references that should be redirected to the new > place. Is there any way besides maintaining a list in the > apache2/nginx configuration and making redirects as we find broken > references? Can we proactively manage this? Is anybody willing to come > up with a script and nginx configuration for doing this? I'm not aware of any tools that might be able to help here. Indeed, it would be great if anyone would volunteer to generate a script to generate the redirects. I guess the old format is e.g. http://openbsc.osmocom.org/trac/wiki/nanoBTS/Internals and the new URL would be something like http://projects.osmocom.org/redmine/openbsc/wiki/nanoBTS/Internals Or should we strip even the redmine from the URL? And should we have a rewrite for http://openbsc.osmocom.org/redmine to http://projects.osmocom.org/redmine/openbsc ? Any ideas? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Fri Feb 5 20:57:12 2016 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 5 Feb 2016 21:57:12 +0100 Subject: Moving from trac to a single redmine In-Reply-To: <20160205161054.GE10932@nataraja> References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160205161054.GE10932@nataraja> Message-ID: Hi, >> I think some of us would like to move to redmine and start using >> public tickets more frequently. So in case we move there are some >> topics to be discussed and I would like to start with a couple of them >> right now. +1 for redmine. >> In terms of installations the GMR trac is broken in regard to tickets, >> there are some for SDR that are probably not being fixed anytime soon, >> baseband might be relevant and OpenBSC is unlikely to be relevant. I >> don't think we have ever used ticket reference in OpenBSC commit >> messages so in terms of OpenBSC having changing ticket numbers would >> not be a big deal. E.g. we could add a custom field with the old trac >> number? > > If there is automatic import/conversion available, I'd prefer to import > the OsmocomBB, SIMtrace, (non-spam) Security and OpenBSC tickets, even > though most of them are probably stale and outdated for years. They're > still part of the history. Changing the numbers doesn't matter, as we > don't refer to them. - OsmocomBB never used tickets AFAIK. - OsmocomGMR definitely never used them - OsmocomSDR ... don't think it's worth importing. - Security ... yeah maybe, although not really sure anyone is really using this. >> We have external references that should be redirected to the new >> place. Is there any way besides maintaining a list in the >> apache2/nginx configuration and making redirects as we find broken >> references? Can we proactively manage this? Is anybody willing to come >> up with a script and nginx configuration for doing this? > > I'm not aware of any tools that might be able to help here. > > Indeed, it would be great if anyone would volunteer to generate a script > to generate the redirects. script ? The page names should be the same, so it should pretty much be just a few redirects per project with regexp to redirect properly. Shouldn't be too hard once we settled for a URL scheme. Any reason not to go for just http://osmocom.org/ as a base ? We have nothing really in the front page and we could just let redmine handle it too. Then just http://osmocom.org/projectname/wiki/page/name looks good to me if doable. Cheers, Sylvain From henk.vergonet at gmail.com Mon Feb 8 10:52:59 2016 From: henk.vergonet at gmail.com (Henk) Date: Mon, 8 Feb 2016 11:52:59 +0100 Subject: [patch]: rtl_sdr, fix -n parameter In-Reply-To: References: Message-ID: Hmm rtl_sdr no longer maintained? So the who can tell us which rtl_sdr code branch is now the defacto standard? Regards On Mon, Jan 11, 2016 at 5:32 PM, Henk wrote: > Fix bytes_to_read adjustment in callback. > > For example bug exposes itself with: > rtl_sdr -f 100e6 -s 2048000 -n 245.76e6 /tmp/100M.iq > and does not terminate after the expected 245.76e6 samples. > Which is an exact multiple of "out_block_size". > > Signed-off-by: Henk vergonet From j-pi at seznam.cz Mon Feb 15 13:28:22 2016 From: j-pi at seznam.cz (P) Date: Mon, 15 Feb 2016 14:28:22 +0100 Subject: [PATCH] allow both >=3.7.4 and git version of GnuRadio Message-ID: <56C1D276.5030203@seznam.cz> This patch make GnuRadion version less strict and allows build with GnuRadio 3.8 (current git version). It makes live more bearable for those of us who live on bleeding edge. P -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-allow-both-3.7.-and-git-version-of-GnuRadio.patch Type: text/x-patch Size: 1030 bytes Desc: not available URL: From kmalittl1 at gmail.com Thu Feb 18 18:31:59 2016 From: kmalittl1 at gmail.com (Mark Richards) Date: Thu, 18 Feb 2016 13:31:59 -0500 Subject: Status of Hardware Message-ID: <56C60E1F.20302@gmail.com> Greetings. As I am looking to build a multi-channel NBFM communications recording device for a public service event, I'd like to know the status of the Osmocom hardware. I can use the RTL-SDR, but perhaps a board with more horsepower would be good. /K1MGY From 246tnt at gmail.com Thu Feb 18 18:37:09 2016 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 18 Feb 2016 19:37:09 +0100 Subject: Status of Hardware In-Reply-To: <56C60E1F.20302@gmail.com> References: <56C60E1F.20302@gmail.com> Message-ID: Hi, > As I am looking to build a multi-channel NBFM communications recording > device for a public service event, I'd like to know the status of the > Osmocom hardware. I can use the RTL-SDR, but perhaps a board with more > horsepower would be good. It's on hold indefinitely. You should look at the hackrf / bladerf / usrp. Cheers, Sylvain From laforge at gnumonks.org Thu Feb 18 18:43:18 2016 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 Feb 2016 19:43:18 +0100 Subject: Moving from trac to a single redmine In-Reply-To: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> Message-ID: <20160218184318.GW4570@nataraja> Hi Holger, let's move ahead and start with the migration, I can't wait to put all the various tickets into a public redmine. Thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Thu Feb 18 18:52:55 2016 From: holger at freyther.de (Holger Freyther) Date: Thu, 18 Feb 2016 19:52:55 +0100 Subject: Moving from trac to a single redmine In-Reply-To: <20160218184318.GW4570@nataraja> References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160218184318.GW4570@nataraja> Message-ID: <753DCDAF-0723-4EC5-8E3C-870B7D5959C5@freyther.de> > On 18 Feb 2016, at 19:43, Harald Welte wrote: > > Hi Holger, Hi all! > > let's move ahead and start with the migration, I can't wait to put all > the various tickets into a public redmine. last weekend I used the "stock" redmine trac->redmine converter and the result is on projects.osmocom.org. It is not perfect but I think good enough to start moving. We see that certain formating needs a post-import correction but that should be doable by all of us quickly. My plan/timeline (on short notice but I don't expect a major resistence so I hope it is fine): * Patch the redmine importer to not import tickets. This hopefully allows me to import other tracs at the same time (and re-add the security tickets by hand) * Friday evening set the tracs to read-only (I probably move the account file away) * Saturday/Sunday do the migration of the trac. * Make it available on osmocom.org (currently it is projects.osmocom.org) * Keep the trac as read-only version for now In the mid-term: * We need to post-process some pages and move them around to have a better structure * Add permanent redirects from the trac to osmocom.org for "approved" content. This way normal traffic will automatically move to the new page and then we can look at the access.log for which pages still need a re-direct. any objections? holger From holger at freyther.de Fri Feb 19 07:09:59 2016 From: holger at freyther.de (Holger Freyther) Date: Fri, 19 Feb 2016 08:09:59 +0100 Subject: Moving from trac to a single redmine In-Reply-To: <20160218231601.GC18542@dub6> References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160218184318.GW4570@nataraja> <753DCDAF-0723-4EC5-8E3C-870B7D5959C5@freyther.de> <20160218231601.GC18542@dub6> Message-ID: > On 19 Feb 2016, at 00:16, Neels Hofmeyr wrote: > > > nitpick: I notice that in redmine, the project name "Openbsc" should > probably be capitalized ("OpenBSC")? The redmine importer insists only works if I enter "openbsc" and then it apparently does "Openbsc" with it. But we can fix that after the import. >> * Saturday/Sunday do the migration of the trac. > > was I too quick then? I'll recreate my account again if necessary. I think we do not need to remove accounts. We might have to fix the email address of contributors that got their account automatically created as part of the import. > >> any objections? > > no problem, since we're all idling around all the time anyway ;) > More seriously though, the wiki is on my todo list to explain gtphub and > adjust that overview png, also to include Iu. Some day not too far I hope... The wiki conversion is not that great. We really have to do some work in post processing and making sure that all content has been migrated. E.g. "Software/Overview" and "SoftwareOverview" seem to confuse the importer: http://projects.osmocom.org/projects/baseband/wiki/SoftwareOverview vs. http://bb.osmocom.org/trac/wiki/Software/Overview vs. http://bb.osmocom.org/trac/wiki/SoftwareOverview So there will be some fallout but I think it still makes sense to move forward now. holger From henk.vergonet at gmail.com Fri Feb 19 12:30:29 2016 From: henk.vergonet at gmail.com (Henk) Date: Fri, 19 Feb 2016 13:30:29 +0100 Subject: Moving from trac to a single redmine In-Reply-To: References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160218184318.GW4570@nataraja> <753DCDAF-0723-4EC5-8E3C-870B7D5959C5@freyther.de> <20160218231601.GC18542@dub6> Message-ID: Any news on the osmocom-sdr tree maintenance? As a last resort, if nobody steps in, I would like to have a go, in order to get some immediate fixes in... and would be happy to leave once you guys have some other candidate. :) Regards, Henk From holger at freyther.de Fri Feb 19 20:00:42 2016 From: holger at freyther.de (Holger Freyther) Date: Fri, 19 Feb 2016 21:00:42 +0100 Subject: Moving from trac to a single redmine In-Reply-To: References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160218184318.GW4570@nataraja> <753DCDAF-0723-4EC5-8E3C-870B7D5959C5@freyther.de> <20160218231601.GC18542@dub6> Message-ID: > On 19 Feb 2016, at 08:09, Holger Freyther wrote: > > > The wiki conversion is not that great. We really have to do some work in post processing and making sure that all content has been migrated. E.g. "Software/Overview" and "SoftwareOverview" seem to confuse the importer: > > http://projects.osmocom.org/projects/baseband/wiki/SoftwareOverview vs. http://bb.osmocom.org/trac/wiki/Software/Overview vs. http://bb.osmocom.org/trac/wiki/SoftwareOverview I am fixing this but if somebody wants to help with some code/regexp it would be nice too. In trac we have: [[Image(motorola_filter_replacement_step_1_low.jpg, 250px)]] For redmine we need: {{thumbnail(motorola_filter_replacement_step_1_low.jpg, size=250)}} Anyone wants to try his luck with a regexp to do this automatically? Or a bit of ruby code to split and manipulate if it is matching [[Image? From elofssonjens at gmail.com Fri Feb 19 22:01:14 2016 From: elofssonjens at gmail.com (Jens Elofsson) Date: Fri, 19 Feb 2016 23:01:14 +0100 Subject: Moving from trac to a single redmine In-Reply-To: References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160218184318.GW4570@nataraja> <753DCDAF-0723-4EC5-8E3C-870B7D5959C5@freyther.de> <20160218231601.GC18542@dub6> Message-ID: According to Google, this should do the trick perl -p -i -e 's/\[\[Image\((.+?)\)\]\]/\{\{thumbnail\($1\)\}\}/g' filename.txt (note that it replaces [[Image...]] with {{thumbnail...}} in the file without creating a backup)). /Jens E 2016-02-19 21:00 GMT+01:00 Holger Freyther : > > > On 19 Feb 2016, at 08:09, Holger Freyther wrote: > > > > > > The wiki conversion is not that great. We really have to do some work in > post processing and making sure that all content has been migrated. E.g. > "Software/Overview" and "SoftwareOverview" seem to confuse the importer: > > > > http://projects.osmocom.org/projects/baseband/wiki/SoftwareOverview vs. > http://bb.osmocom.org/trac/wiki/Software/Overview vs. > http://bb.osmocom.org/trac/wiki/SoftwareOverview > > I am fixing this but if somebody wants to help with some code/regexp it > would be nice too. > > In trac we have: > > [[Image(motorola_filter_replacement_step_1_low.jpg, 250px)]] > > For redmine we need: > > {{thumbnail(motorola_filter_replacement_step_1_low.jpg, size=250)}} > > Anyone wants to try his luck with a regexp to do this automatically? Or a > bit of ruby code to split and manipulate if it is matching [[Image? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Fri Feb 19 22:03:10 2016 From: holger at freyther.de (Holger Freyther) Date: Fri, 19 Feb 2016 23:03:10 +0100 Subject: Moving from trac to a single redmine In-Reply-To: References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160218184318.GW4570@nataraja> <753DCDAF-0723-4EC5-8E3C-870B7D5959C5@freyther.de> <20160218231601.GC18542@dub6> Message-ID: <5E9E5F4C-658A-491F-9AD7-9B7418238A5C@freyther.de> > On 19 Feb 2016, at 08:09, Holger Freyther wrote: > > > The wiki conversion is not that great. We really have to do some work in post processing and making sure that all content has been migrated. E.g. "Software/Overview" and "SoftwareOverview" seem to confuse the importer: > > http://projects.osmocom.org/projects/baseband/wiki/SoftwareOverview vs. http://bb.osmocom.org/trac/wiki/Software/Overview vs. http://bb.osmocom.org/trac/wiki/SoftwareOverview > > So there will be some fallout but I think it still makes sense to move forward now. This post is Sponsored by the Ministry of Stuff you Didn't want to know. Trac has a "flat" wiki model. The hierarchy is added by the notion of adding / into the path. This means that SoftwareOverview is a top-level page and Software/Overview is a child of software. In Redmine there is the concept of "parent" pages but the name is a flat namespace. So by convention the page would be called "Overview" but be a child of "Software". Redmine will normalize a pagetitle like Software/Overview to SoftwareOverview. To avoid having "SoftwareOverview" and "Software/Overview" clash I am expanding the later to SoftwareSoftwareOverview and this gives us funny names and broken links (*sigh*) but with reasonable effort this seems to be as good as I can get it. This means our manual fix-up step will so far include: * Fix general format issue (e.g. 
 but no
) * Remove custom html I created to have a multi-column view. * Fix the [[Image unless I get the regexp to work in ruby * Rename SoftwareSoftwareOverview and other pages (and delete the old one) kind regards holger From horiz0n at gmx.net Sun Feb 28 17:00:56 2016 From: horiz0n at gmx.net (Dimitri Stolnikov) Date: Sun, 28 Feb 2016 18:00:56 +0100 Subject: [PATCH] allow both >=3.7.4 and git version of GnuRadio In-Reply-To: <56C1D276.5030203@seznam.cz> References: <56C1D276.5030203@seznam.cz> Message-ID: Thanks, applied. On Mon, 15 Feb 2016 14:28:22 +0100, P wrote: > This patch make GnuRadion version less strict and allows build with > GnuRadio 3.8 (current git version). > > It makes live more bearable for those of us who live on bleeding edge. > > P From horiz0n at gmx.net Sun Feb 28 17:00:55 2016 From: horiz0n at gmx.net (Dimitri Stolnikov) Date: Sun, 28 Feb 2016 18:00:55 +0100 Subject: Airspy patch to enable USB bit packing In-Reply-To: <5692F758.6080900@yahoo.ie> References: <5692F758.6080900@yahoo.ie> Message-ID: Thanks, applied. On Mon, 11 Jan 2016 01:29:12 +0100, Martin Smith wrote: > Last July there were several changes made to the Airspy firmware and > libairspy that added support for a new bit packing mode where 4 sets of > 12 bit samples are packed into 3 sets of 16 bits for the transfer across > the USB bus ( https://i.imgur.com/qXnWoEK.png?1 ). 25% less data is > transferred across the bus and this is good for some computers with > cheap USB chipsets. There is an overhead of extra memory bandwidth > required on the host side to unpack the data into a useful format, so > for optimal performance bit packing is disabled by default. > > The data is automatically unpacked within libairspy before being passed > along, so no changes are required anywhere else if packing is enabled > (or not enabled). Airspy firmware older than v1.0.0-rc6 does not have > the function, but that is detected and handled by libairspy. > > I wrote the attached patch to enable packing in gr-osmosdr, which I > tested and it works. It is basically a clone of the bias=0|1 lines as > pack=0|1 and calls the needed libairspy function. > > ref: > https://github.com/airspy/firmware/commit/7e1806b > https://github.com/airspy/firmware/commit/5b7dcab > https://github.com/airspy/host/commit/a51eccb > > > --- > Do some Baseline test with Airspy command line tools to have something > to compare USB throughput results > -------------------------------------------------------------------------------------------------------- > $ sudo mount -t debugfs none /sys/kernel/debug > $ sudo modprobe usbmon > $ wireshark -i usbmod3 & > $ airspy_info ; sleep 120 ; \ > airspy_rx -t 4 -r /dev/null -n 2400000000 ; sleep 120 ; \ > airspy_rx -t 4 -r /dev/null -p 1 -n 2400000000 ; sleep 120 ; \ > airspy_info > Wireshark->Statistics->IO Graph > The Bytes/Tick are double the actual data rate because of way wireshark > collects the USB packets, I could have added a filter to fix this. But > the relationship is valid 25% less with packing enabled. The data rate > in the IO Grahp drops from 80MB/sec (in+out) [really 40MB/sec] to > 60MB/second (in+out) [really 30MB/sec] from unpacked to packed. > 10MSPS no packing, packing https://i.imgur.com/pA9LPdE.png?1 > 2.5MSPS no packing, packing https://i.imgur.com/lA8q5aq.png?1 > > > Verification test with my patched gr-osmosdr > -------------------------------------------- > $ sudo mount -t debugfs none /sys/kernel/debug > $ sudo modprobe usbmon > $ wireshark -i usbmod3 & > $ osmocom_fft -a "airspy=0" -s 10000000 --fft-rate=1 > $ osmocom_fft -a "airspy=0,pack=1" -s 10000000 --fft-rate=1 > $ osmocom_fft -a "airspy=0" -s 2500000 --fft-rate=1 > $ osmocom_fft -a "airspy=0,pack=1" -s 2500000 --fft-rate=1 > $ osmocom_fft -a "airspy=0" -s 2500000 --fft-rate=1 > $ osmocom_fft -a "airspy=0,pack=0" -s 2500000 --fft-rate=1 > > I ran all of the above tests and the wireshark USB throughput graphs > showed exactly what was expected. > 40MB/sec(10MSPS+normal),30MB/sec(10MSPS+packing),10MB/sec(2.5MSPS+normal),7.5MB/sec(2.5MSPS+packing),10MB/sec(2.5MSPS+normal),10MB/sec(2.5MSPS+normal). > > 25% less when packing was enabled and if you did not specify the > "pack=1", then no bit packing is performed by libairspy. All the > magnitudes within the FFT windows looked exactly the same as they do > without bit packing. From jdpoirier at gmail.com Sun Feb 28 18:11:35 2016 From: jdpoirier at gmail.com (Joseph Poirier) Date: Sun, 28 Feb 2016 12:11:35 -0600 Subject: post a new release Message-ID: If would be nice to have a newer official release available; installation using the package manager on many Linux distros gets a two year old librtlsdr that's missing the rtlsdr_set_tuner_bandwidth function (added about nine months ago), as well as, other nice updates and fixes. cheers, joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From henk.vergonet at gmail.com Mon Feb 29 17:31:01 2016 From: henk.vergonet at gmail.com (Henk) Date: Mon, 29 Feb 2016 18:31:01 +0100 Subject: post a new release In-Reply-To: References: Message-ID: +1 Hmm in my opinion rtl_sdr is the next best thing since the invention of canned beer :) since it liberated the airwaves for allot of users. From henk.vergonet at gmail.com Mon Feb 29 17:34:08 2016 From: henk.vergonet at gmail.com (Henk) Date: Mon, 29 Feb 2016 18:34:08 +0100 Subject: post a new release In-Reply-To: References: Message-ID: Oeps, sorry forgot to quote the original post of joseph. +1 Hmm in my opinion rtl_sdr is the next best thing since the invention of canned beer :) since it liberated the airwaves for allot of users. Regards, henk On Sun, Feb 28, 2016 at 7:11 PM, Joseph Poirier wrote: > If would be nice to have a newer official release available; installation > using the package manager on many Linux distros gets a two year old > librtlsdr that's missing the rtlsdr_set_tuner_bandwidth function (added > about nine months ago), as well as, other nice updates and fixes. > > cheers, > joe From ashishbnv at gmail.com Wed Feb 24 16:19:42 2016 From: ashishbnv at gmail.com (Ashish Kurian) Date: Wed, 24 Feb 2016 16:19:42 -0000 Subject: rtl_test Message-ID: Hi, When I run the command rtl_test I get the message like Reading samples in async mode and then there is no output. But when I give commands like rtl_test -p I get the expected output. Please help me in fixing this issue. Best Regards, Ashish Kurian From nhofmeyr at sysmocom.de Thu Feb 18 23:30:00 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 18 Feb 2016 23:30:00 -0000 Subject: Moving from trac to a single redmine In-Reply-To: <753DCDAF-0723-4EC5-8E3C-870B7D5959C5@freyther.de> References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160218184318.GW4570@nataraja> <753DCDAF-0723-4EC5-8E3C-870B7D5959C5@freyther.de> Message-ID: <20160218231601.GC18542@dub6> On Thu, Feb 18, 2016 at 07:52:55PM +0100, Holger Freyther wrote: > last weekend I used the "stock" redmine trac->redmine converter and the result is on projects.osmocom.org. It is not perfect but I think good enough to start moving. We see that certain formating needs a post-import correction but that should be doable by all of us quickly. I swiftly registered a 'neels' account and as soon as it's granted project memberships, I'd start off by making the overview png visible inline on the OpenBSC wiki page (unless we can automate those somehow). nitpick: I notice that in redmine, the project name "Openbsc" should probably be capitalized ("OpenBSC")? > * Saturday/Sunday do the migration of the trac. was I too quick then? I'll recreate my account again if necessary. > any objections? no problem, since we're all idling around all the time anyway ;) More seriously though, the wiki is on my todo list to explain gtphub and adjust that overview png, also to include Iu. Some day not too far I hope... ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Holger Freyther, Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From momchil at xaxo.eu Sun Feb 21 18:44:16 2016 From: momchil at xaxo.eu (Momchil Ivanov) Date: Sun, 21 Feb 2016 18:44:16 -0000 Subject: Building rtl-sdr under mingw64 Message-ID: <79f24fd27892079dcbc325d92dbddd59.squirrel@webmail.xaxo.eu> Hi, I was trying to build rtl-sdr on windows using mingw64 and stumbled upon the error described here [1] [ 40%] Building C object src/CMakeFiles/rtl_adsb.dir/rtl_adsb.c.o Linking C executable rtl_adsb.exe libconvenience_static.a(convenience.c.o):convenience.c:(.text+0x1e5): undefined reference to `rtlsdr_set_tuner_gain_mode' libconvenience_static.a(convenience.c.o):convenience.c:(.text+0x1e5): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `rtlsdr_set_tuner_gain_mode' libconvenience_static.a(convenience.c.o):convenience.c:(.text+0x1fb): undefined reference to `rtlsdr_get_tuner_gains' libconvenience_static.a(convenience.c.o):convenience.c:(.text+0x1fb): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `rtlsdr_get_tuner_gains' and so on.... I was able to build rtl-sdr using the attached patch. I exchange the order of linking libraries. 1: http://lists.osmocom.org/pipermail/osmocom-sdr/2015-April/000048.html Greetings, Momchil -------------- next part -------------- A non-text attachment was scrubbed... Name: rtl-sdr.patch Type: application/octet-stream Size: 1628 bytes Desc: not available URL: