[Discuss-gnuradio] Re: make question about building a signal processing block
Zhenghao Zhang wrote am 2008-05-19 18:47: Hi, I ran aclocal, autoconf, ./configure, all seemed to be fine. Then I ran automake, which gave me these mesages: [EMAIL PROTECTED] trytry]# automake doc/Makefile.am:77: `%'-style pattern rules are a GNU make extension doc/Makefile.am:80: `%'-style pattern rules are a GNU make extension src/lib/Makefile.am:55: Python sources seen but `PYTHON' is undefined src/lib/Makefile.am:55: The usual way to define `PYTHON' is to add `AM_PATH_PYTHON' Which versions do you have installed? automake, autoconf etc... Have you compared this versions to the versions listed in the README? Which system are you building on (distribution)? Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser patrick dot strasser at student dot tugraz dot at Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How do I checkout an old version
Dear All, I would like to checkout release 3.1.1. How do I do ? svn co -r 3.1.1 http://gnuradio.org/svn/gnuradio/trunk gnuradio doesn't work. BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How do I checkout an old version
On Tue, May 20, 2008 at 10:14 AM, Per Zetterberg [EMAIL PROTECTED] wrote: Dear All, I would like to checkout release 3.1.1. How do I do ? svn co -r 3.1.1 http://gnuradio.org/svn/gnuradio/trunk gnuradio doesn't work. You must first change your way of thinking. Instead of the trunk, try thinking of the tags directory: http://gnuradio.org/trac/browser/gnuradio/tags/releases Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How do I checkout an old version
On Tue, May 20, 2008 at 10:56 AM, Per Zetterberg [EMAIL PROTECTED] wrote: So svn co -r6823 http://gnuradio.org/svn/gnuradio/trunk gnuradio Or you can just pull directly from http://gnuradio.org/svn/gnuradio/tags/releases/3.1.1/ without specifying the -r6823. Whichever you want. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] How do I checkout an old version
-Original Message- From: Brian Padalino [mailto:[EMAIL PROTECTED] Sent: den 20 maj 2008 16:18 To: Per Zetterberg Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How do I checkout an old version On Tue, May 20, 2008 at 10:14 AM, Per Zetterberg [EMAIL PROTECTED] wrote: Dear All, I would like to checkout release 3.1.1. How do I do ? svn co -r 3.1.1 http://gnuradio.org/svn/gnuradio/trunk gnuradio doesn't work. You must first change your way of thinking. Instead of the trunk, try thinking of the tags directory: http://gnuradio.org/trac/browser/gnuradio/tags/releases Brian So svn co -r6823 http://gnuradio.org/svn/gnuradio/trunk gnuradio BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question
Hi, I'm working on a OFDM simulation based on gnuradio libreires. I would like to modify the band-width of all my carriers, that from sperimental tests results about 1 kHz, but i don't know in which source i can find it, or , if other people had work on it, if there is some program or function with which i can obtain my aim. Thank you very much for the reply Matteo _ Una cena tra amici? Cerca il ristorante con Live Search Maps http://maps.live.it___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How do I checkout an old version
On Tue, May 20, 2008 at 8:00 AM, Brian Padalino [EMAIL PROTECTED] wrote: On Tue, May 20, 2008 at 10:56 AM, Per Zetterberg [EMAIL PROTECTED] wrote: So svn co -r6823 http://gnuradio.org/svn/gnuradio/trunk gnuradio Or you can just pull directly from http://gnuradio.org/svn/gnuradio/tags/releases/3.1.1/ without specifying the -r6823. Whichever you want. The release tarballs are made from the release branch, not the trunk, so the only ways to get release 3.1.1 are to either use the tagged directory (as you sshow), or to use a revision specifier on http://gnuradio.org/svn/branches/releases/3.1. The trunk contains many in-progress things that don't get put into the release branch. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How do I checkout an old version
On Tue, May 20, 2008 at 11:00:42AM -0400, Brian Padalino wrote: On Tue, May 20, 2008 at 10:56 AM, Per Zetterberg [EMAIL PROTECTED] wrote: So svn co -r6823 http://gnuradio.org/svn/gnuradio/trunk gnuradio Or you can just pull directly from http://gnuradio.org/svn/gnuradio/tags/releases/3.1.1/ without specifying the -r6823. Whichever you want. Brian These are not equivalent. If you want the 3.1.1 release, use svn co http://gnuradio.org/svn/gnuradio/tags/releases/3.1.1 For details on subversion, including the concepts of trunk, branches and tags, see the Red Bean Subversion Book. http://svnbook.red-bean.com Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packets and m-blocks
Gregory Maxwell wrote: Greetings. Some time ago created a number of GNURadio signal processing blocks for audio codecs, and have recently gotten around to finishing them up for public release (Speex and CELT, along with the speex acoustic echo canceler). Constant bitrate support was a piece of cake (and wow does Speex sound better than GSM FR, I forgot how bad GSM was... ;) ) However, I'm stuck on supporting variable bitrate mode. I basically want to present a variable sized packet interface for the coded side. It seems that the m-block code is what I want to use for that ... but I can't find any examples of m-block code that I could emulate. Can someone kick me in the right direction? Hi Gregory, I don't know if there is any way around this using the regular GNU Radio blocks, m-blocks do allow variable sized messages in between blocks, however there is no support for m-block-gr-block connections yet. I believe Eric is scheduled to work on this soon. So in summary, yes the m-blocks could solve your problem, but they are not ready for use with the rest of the GNU Radio code base yet. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC bug in Variable Sink
Josh, I believe I've uncovered a bug in the Variable Sink block. It seems to work fine when the input type is float, but fails to function correctly when the input type is either int or short. The flowgraph continues to run, but the variable is either set to zero of does not change at all. I'm trying to use it to add a command port to a flowgraph that receives a single int or short from an external application (via a UDP Source block), and uses it to tune a doppler correction. @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Modulation problem ?
Steven Clark-2 wrote:
This is not surprising. It is likely that you are getting some initial
garbage (non-standard-ascii characters) coming out, or that you have
some bit errors.
Don't open it in gedit. Try:
python
f = open('Resultat.txt')
d = f.read()
f.close()
print(len(d))
print(d)
(or if d is really long, print(d[:50]))
When I tried this and
$ cat Resultat.txt
or even
$ less Resultat.txt
on the Terminal I didn't see anything at first but copying what seemed empty
into a file, I got:
Re: [Discuss-gnuradio] Another question about making a signal processing block
Eric, Thanks a lot for the help. I tried your commands and it is working now. I can build a signal processing block and run qa tests. Thanks so much. It took me a while to because there were some bugs in my files. Zhenghao On Mon, May 19, 2008 at 11:48 PM, Zhenghao Zhang [EMAIL PROTECTED] wrote: Eric, Thanks so much! I will try them first time tomorrow morning. Zhenghao On Mon, May 19, 2008 at 11:30 PM, Eric Blossom [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 10:45:41PM -0400, Zhenghao Zhang wrote: Thanks for helping me on this! autoconf (GNU Autoconf) 2.61 automake (GNU automake) 1.10 OK, those look fine. Try this: rm -fr config.cache autom4te*.cache aclocal -I config autoconf autoheader libtoolize --automake automake --add-missing -c -f -Wno-portability ./configure make make check [I realized that we're not distributing the bootstrap script with the tarballs. I'll fix that in a minute.] Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tracing a connection stack
Is there a simple way to print out a list of what was connected into a flow graph? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: make question about building a signal processing block
Thanks for helping me on this. Eric also asked the same question and it seemed that my automake and autoconf versions are fine. Eric also told me a few commands, which I ran and now everything is fine. Thank you again for your time. Zhenghao On Tue, May 20, 2008 at 7:28 AM, Patrick Strasser [EMAIL PROTECTED] wrote: Zhenghao Zhang wrote am 2008-05-19 18:47: Hi, I ran aclocal, autoconf, ./configure, all seemed to be fine. Then I ran automake, which gave me these mesages: [EMAIL PROTECTED] trytry]# automake doc/Makefile.am:77: `%'-style pattern rules are a GNU make extension doc/Makefile.am:80: `%'-style pattern rules are a GNU make extension src/lib/Makefile.am:55: Python sources seen but `PYTHON' is undefined src/lib/Makefile.am:55: The usual way to define `PYTHON' is to add `AM_PATH_PYTHON' Which versions do you have installed? automake, autoconf etc... Have you compared this versions to the versions listed in the README? Which system are you building on (distribution)? Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser patrick dot strasser at student dot tugraz dot at Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tracing a connection stack
On Tue, May 20, 2008 at 12:09:27PM -0500, Brett L. Trotter wrote: Is there a simple way to print out a list of what was connected into a flow graph? Not right now. However, just last night I was thinking about something similar. Give me a day or so and I'll put something together. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tracing a connection stack
On Tue, May 20, 2008 at 11:07 AM, Eric Blossom [EMAIL PROTECTED] wrote: On Tue, May 20, 2008 at 12:09:27PM -0500, Brett L. Trotter wrote: Is there a simple way to print out a list of what was connected into a flow graph? Not right now. However, just last night I was thinking about something similar. Give me a day or so and I'll put something together. Eric--there is a dump() method on gr_flat_flowgraph objects currently used for debugging. You can create a method on gr.top_block (exposed via swig) that would call dump() on the d_ffg member. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: make question about building a signal processing block
On Tue, May 20, 2008 at 01:10:57PM -0400, Zhenghao Zhang wrote: Thanks for helping me on this. Eric also asked the same question and it seemed that my automake and autoconf versions are fine. Eric also told me a few commands, which I ran and now everything is fine. Thank you again for your time. Zhenghao I've added the bootstrap script to the files that are distributed in the tarballs. It'll be in the next release. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tracing a connection stack
On Tue, May 20, 2008 at 11:14:18AM -0700, Johnathan Corgan wrote: On Tue, May 20, 2008 at 11:07 AM, Eric Blossom [EMAIL PROTECTED] wrote: On Tue, May 20, 2008 at 12:09:27PM -0500, Brett L. Trotter wrote: Is there a simple way to print out a list of what was connected into a flow graph? Not right now. However, just last night I was thinking about something similar. Give me a day or so and I'll put something together. Eric--there is a dump() method on gr_flat_flowgraph objects currently used for debugging. You can create a method on gr.top_block (exposed via swig) that would call dump() on the d_ffg member. Thanks! FYI, I opened it as ticket:245 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tracing a connection stack
Eric Blossom wrote: On Tue, May 20, 2008 at 11:14:18AM -0700, Johnathan Corgan wrote: On Tue, May 20, 2008 at 11:07 AM, Eric Blossom [EMAIL PROTECTED] wrote: On Tue, May 20, 2008 at 12:09:27PM -0500, Brett L. Trotter wrote: Is there a simple way to print out a list of what was connected into a flow graph? Not right now. However, just last night I was thinking about something similar. Give me a day or so and I'll put something together. Eric--there is a dump() method on gr_flat_flowgraph objects currently used for debugging. You can create a method on gr.top_block (exposed via swig) that would call dump() on the d_ffg member. Thanks! FYI, I opened it as ticket:245 Eric Most excellent. Thank you for the reply and the solution. Just debugging some code and I think it's just omission, but wanted to see if there's something connected higher up- it seemed being able to see what all was hooked up would be handy. Cheers and thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC bug in Variable Sink
Forgot to mention I'm using GRC 0.69 and GnuRadio 3.1.1 @(^.^)@ Ed Ed Criscuolo wrote: Josh, I believe I've uncovered a bug in the Variable Sink block. It seems to work fine when the input type is float, but fails to function correctly when the input type is either int or short. The flowgraph continues to run, but the variable is either set to zero of does not change at all. I'm trying to use it to add a command port to a flowgraph that receives a single int or short from an external application (via a UDP Source block), and uses it to tune a doppler correction. @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tracing a connection stack
Brett L. Trotter wrote: Thanks! FYI, I opened it as ticket:245 Eric Most excellent. Thank you for the reply and the solution. Just debugging some code and I think it's just omission, but wanted to see if there's something connected higher up- it seemed being able to see what all was hooked up would be handy. Cheers and thanks! The latest trunk now has an added method to gr.top_block, dump(), that will dump the runtime flattened flowgraph and connectivity. However, it is only valid after calling start() on the top block, as that is when the hierarchy gets flattened and pruned, to be passed to the scheduler. In other words, you can replace: tb.run() ...with: tb.start() # Results in the hierarchy being flattened and pruned tb.dump() # Dumps the flattened flowgraph to stdout tb.wait() # Continues with the rest of what run() would have done What would be better of course is a dump method that would show the hierarchy, etc., as noted in Trac ticket #245. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC bug in Variable Sink
Ed Criscuolo wrote: Forgot to mention I'm using GRC 0.69 and GnuRadio 3.1.1 @(^.^)@ Ed Ed Criscuolo wrote: Josh, I believe I've uncovered a bug in the Variable Sink block. It seems to work fine when the input type is float, but fails to function correctly when the input type is either int or short. The flowgraph continues to run, but the variable is either set to zero of does not change at all. Ed, Its seems that the variable sink casts the number to a float: numpy.fromstring (s, numpy.float32) regardless of the input type. I admit that I didnt know 100% what i was doing when I made this variable sink... So, only use the variable sink as a float input type, and place a short to float converter between the udp sink and the variable sink. (there is currently no int to float converter in gnuradio) I hope that works! Since it seems to be useful, I will make a shiny new variable sink in the grc trunk. BTW, there is a converter script now for older flow graphs if you are willing to try it out. -Josh I'm trying to use it to add a command port to a flowgraph that receives a single int or short from an external application (via a UDP Source block), and uses it to tune a doppler correction. @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Need a Software (S/W) professional with OS and Kernel level experience
Hello everyone, We need a reasonably experienced Software (S/W) person (4+ experience would be great) who has worked on OS and Kernel level issues or OS specific S/W system integration for any type of application, protocol codes or external S/W programs in general. It would be great if the person has experience in Mobile Operating Systems - Linux, CE, OSX or Symbian but if not, that's not a barrier. Folks who have worked in S/W system integration to OS or worked with some kernels to fix S/W or App level issues should be able to do the job. The knowledge of working with OS Kernels is important. Experience with Bluetooth, WiFi protocols or any other Mobile protocol is a great + The requirement is urgent. Please let me know if you can help yourself or can think of someone. The position can be based around NYC, in the Bay Area or in India. The compensation will be based out of Stocks initially (or some cash component depending upon the expertise and implementation) - It could be either a consulting assignment for a month or so OR an entrepreneurial role as part of the founding team (the first task requires about a month worth of effort - after which it will continue on an ongoing basis) If you are on a job and looking to venture out, we would be willing to work around your schedule. Many thanks for your time Sanjiv Rai Founder and CEO UNIRF ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC bug in Variable Sink
Josh Blum wrote: Ed, Its seems that the variable sink casts the number to a float: numpy.fromstring (s, numpy.float32) regardless of the input type. I admit that I didnt know 100% what i was doing when I made this variable sink... So, only use the variable sink as a float input type, and place a short to float converter between the udp sink and the variable sink. (there is currently no int to float converter in gnuradio) I hope that works! Yes, that's what I've been doing. It works. I've also written the missing gr_int_to_float and gr_float_to_int blocks, as well as a gr_network_to_host_ii byte order swapper block. If there's general interest in these blocks, I can submit them for inclusion in GnuRadio. Since it seems to be useful, I will make a shiny new variable sink in the grc trunk. BTW, there is a converter script now for older flow graphs if you are willing to try it out. Sure. How do I get to it? @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UK shops track customers via GNU Radio monitoring their mobile phones!
Danny O'Brien of EFF pointed out this profile of Toby Oliver of Path Intelligence, which uses GNU Radio to build phone-monitoring networks for shops: http://www.cnet.com/8301-13505_1-9734052-16.html Toby Oliver, CEO of Path Intelligence, is based in Portsmouth, England, where he and his wife, Sharon, have built a hugely interesting (and innovative) product on top of the GNU Radio open source project, key parts of which they've helped to fund. The social impact is covered here: http://technology.timesonline.co.uk/tol/news/tech_and_web/article3945496.ece (text below.) and here: http://p10.hostingprod.com/@spyblog.org.uk/blog/2008/05/path-intelligence-phorm-for-shopping-centres.html (See the comments for pointers to patents and such.) http://www.techcrunch.com/2007/12/14/path-intelligence-monitors-foot-traffic-in-retail-stores-by-pinging-peoples-phones/ Of course, though they say this data isn't correlated with any other info, all it would take is recording what image is taken by the security cameras when an identifiable mobile phone walks by. And with what charge card was used at the cash register when that same phone is standing in front of it. And the license plate number (and the RFID's in the tires) of the car that's going past when this mobile phone passes your reader. Then you have the user's picture, name, credit card info, car registration, and maybe tyre RFIDs; all without the help of the mobile operator. Removing the battery from your mobile phone is going to get a lot more popular, I expect. But at least we'll have free software tools for monitoring what info it's leaking about you when the battery is in. (How much of the Path Intelligence modules are in the main GR repository?) John Shops track customers via mobile phone May 16, 2008 Customers in shopping centres are having their every move tracked by a new type of surveillance that listens in on the whisperings of their mobile phones. The technology can tell when people enter a shopping centre, what stores they visit, how long they remain there, and what route they take as they walked around. The device cannot access personal details about a person?s identity or contacts, but privacy campaigners expressed concern about potential intrusion should the data fall into the wrong hands. The surveillance mechanism works by monitoring the signals produced by mobile handsets and then locating the phone by triangulation ? measuring the phone?s distance from three receivers. It has already been installed in two shopping centres, including Gunwharf Quays in Portsmouth, and three more centres will begin using it next month, Times Online has learnt. The company that makes the dishes, which measure 30cm (12 inches) square and are placed on walls around the centre, said that they were useful to centres that wanted to learn more about the way their customers used the store. A shopping mall could, for example, find out that 10,000 people were still in the store at 6pm, helping to make a case for longer opening hours, or that a majority of customers who visited Gap also went to Next, which could useful for marketing purposes. In the case of Gunwharf Quays, managers were surprised to discover that an unusually high percentage of visitors were German - the receivers can tell in which country each phone is registered - which led to the management translating the instructions in the car park. The Information Commissioner's Office (ICO) expressed cautious approval of the technology, which does not identify the owner of the phone but rather the handset's IMEI code - a unique number given to every device so that the network can recognise it. But an ICO spokesman said, we would be very worried if this technology was used in connection with other systems that contain personal information, if the intention was to provide more detailed profiles about identifiable individuals and their shopping habits.? Only the phone network can match a handset's IMEI number to the personal details of a customer. Path Intelligence, the Portsmouth-based company which developed the technology, said its equipment was just a tool for market research. There's absolutely no way we can link the information we gather back to the individual,? a spokeswoman said. ?There's nothing personal in the data. Liberty, the campaign group, said that although the data do not meet the legal definition of ?personal information?, it had the potential to identify particular individuals' shopping habits by referencing information held by the phone networks. The receivers together cost about £20,000 to rent per month. About 20 the units, which are unobtrusive, cream-coloured boxes about the size of a satellite dish, would be needed to cover the Bluewater shopping centre. Bluewater, in Kent, said it had no plans to deploy the equipment. A spokesman for Gunwharf Quays was not available for comment. Owners of large buildings currently have to rely on
Re: [Discuss-gnuradio] UK shops track customers via GNU Radiomonitoring their mobile phones!
John- Danny O'Brien of EFF pointed out this profile of Toby Oliver of Path Intelligence, which uses GNU Radio to build phone-monitoring networks for shops: http://www.cnet.com/8301-13505_1-9734052-16.html Toby Oliver, CEO of Path Intelligence, is based in Portsmouth, England, where he and his wife, Sharon, have built a hugely interesting (and innovative) product on top of the GNU Radio open source project, key parts of which they've helped to fund. Which parts of GNU radio were funded and/or developed by Mr. Oliver and his wife? -Jeff The social impact is covered here: http://technology.timesonline.co.uk/tol/news/tech_and_web/article3945496.ece (text below.) and here: http://p10.hostingprod.com/@spyblog.org.uk/blog/2008/05/path-intelligence-phorm-for-shopping-centres.html (See the comments for pointers to patents and such.) http://www.techcrunch.com/2007/12/14/path-intelligence-monitors-foot-traffic-in-retail-stores-by-pinging-peoples-phones/ Of course, though they say this data isn't correlated with any other info, all it would take is recording what image is taken by the security cameras when an identifiable mobile phone walks by. And with what charge card was used at the cash register when that same phone is standing in front of it. And the license plate number (and the RFID's in the tires) of the car that's going past when this mobile phone passes your reader. Then you have the user's picture, name, credit card info, car registration, and maybe tyre RFIDs; all without the help of the mobile operator. Removing the battery from your mobile phone is going to get a lot more popular, I expect. But at least we'll have free software tools for monitoring what info it's leaking about you when the battery is in. (How much of the Path Intelligence modules are in the main GR repository?) John Shops track customers via mobile phone May 16, 2008 Customers in shopping centres are having their every move tracked by a new type of surveillance that listens in on the whisperings of their mobile phones. The technology can tell when people enter a shopping centre, what stores they visit, how long they remain there, and what route they take as they walked around. The device cannot access personal details about a person?s identity or contacts, but privacy campaigners expressed concern about potential intrusion should the data fall into the wrong hands. The surveillance mechanism works by monitoring the signals produced by mobile handsets and then locating the phone by triangulation ? measuring the phone?s distance from three receivers. It has already been installed in two shopping centres, including Gunwharf Quays in Portsmouth, and three more centres will begin using it next month, Times Online has learnt. The company that makes the dishes, which measure 30cm (12 inches) square and are placed on walls around the centre, said that they were useful to centres that wanted to learn more about the way their customers used the store. A shopping mall could, for example, find out that 10,000 people were still in the store at 6pm, helping to make a case for longer opening hours, or that a majority of customers who visited Gap also went to Next, which could useful for marketing purposes. In the case of Gunwharf Quays, managers were surprised to discover that an unusually high percentage of visitors were German - the receivers can tell in which country each phone is registered - which led to the management translating the instructions in the car park. The Information Commissioner's Office (ICO) expressed cautious approval of the technology, which does not identify the owner of the phone but rather the handset's IMEI code - a unique number given to every device so that the network can recognise it. But an ICO spokesman said, we would be very worried if this technology was used in connection with other systems that contain personal information, if the intention was to provide more detailed profiles about identifiable individuals and their shopping habits.? Only the phone network can match a handset's IMEI number to the personal details of a customer. Path Intelligence, the Portsmouth-based company which developed the technology, said its equipment was just a tool for market research. There's absolutely no way we can link the information we gather back to the individual,? a spokeswoman said. ?There's nothing personal in the data. Liberty, the campaign group, said that although the data do not meet the legal definition of ?personal information?, it had the potential to identify particular individuals' shopping habits by referencing information held by the phone networks. The receivers together cost about �20,000 to rent per month. About 20 the units, which are unobtrusive, cream-coloured boxes about the size of a satellite dish, would be needed to cover the Bluewater
Re: [Discuss-gnuradio] UK shops track customers via GNU Radio monitoring their mobile phones!
On Tue, May 20, 2008 at 01:43:06PM -0700, John Gilmore wrote: (How much of the Path Intelligence modules are in the main GR repository?) Only the multi-usrp work. That includes gnuradio-examples/multi_usrp, the C++ blocks it depends on, and custom FPGA code in usrp/fpga/toplevel/usrp_multi. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] atsc_cpll *almost* works
After converting atsc_fpll to handle complex input (to eliminate one upconverter) it almost works, only the video out has problems. The problem starts when this: float I = input.real() * a_sin; float Q = input.real() * a_cos; is changed to this: gr_complex IQ = input * gr_complex(a_cos,-a_sin); which would be necessary to handle negative frequencies I think. Everything else checks out ok, I even tried using gr_sincos.h in place of gr_nco.h like in gr_pll_carriertracking_cc and it behaves exectly the same. Working: gr_complex input = agc.scale(in[k]); gr_sincosf(d_phase,a_sin,a_cos); float I = input.real() * a_sin; float Q = input.real() * a_cos; out[k] = I; gr_complex filtered_IQ = afc.filter(gr_complex(I,Q)); float x = phase_detector(filtered_IQ,0); static const float alpha = 0.001; static const float beta = alpha * alpha / 4; d_freq = d_freq + beta * x; d_phase = mod_2pi(d_phase + d_freq + alpha * x); mpeg_packet_error_rate.py: 485526 errors out of 2165316 packets. 1679790 good packets. Error rate = 0.224 Almost working: gr_complex input = agc.scale(in[k]); gr_sincosf(d_phase,a_sin,a_cos); gr_complex IQ = input * gr_complex(a_cos,-a_sin); out[k] = IQ.real(); gr_complex filtered_IQ = afc.filter(gr_complex(I,Q)); float x = phase_detector(filtered_IQ,0); static const float alpha = 0.001; static const float beta = alpha * alpha / 4; d_freq = d_freq + beta * x; d_phase = mod_2pi(d_phase + d_freq + alpha * x); mpeg_packet_error_rate.py: 258539 errors out of 2165280 packets. 1906741 good packets. Error rate = 0.119 Looks like a 36 missing packets, even tho the error rate is less, as the video is certainly worse in mplayer. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc_cpll *almost* works
On Tue, May 20, 2008 at 8:52 PM, Charles Swiger [EMAIL PROTECTED] wrote: After converting atsc_fpll to handle complex input (to eliminate one upconverter) it almost works, only the video out has problems. The problem starts when this: float I = input.real() * a_sin; float Q = input.real() * a_cos; is changed to this: gr_complex IQ = input * gr_complex(a_cos,-a_sin); which would be necessary to handle negative frequencies I think. Everything else checks out ok, I even tried using gr_sincos.h in place of gr_nco.h like in gr_pll_carriertracking_cc and it behaves exectly the same. Working: gr_complex input = agc.scale(in[k]); gr_sincosf(d_phase,a_sin,a_cos); float I = input.real() * a_sin; float Q = input.real() * a_cos; out[k] = I; gr_complex filtered_IQ = afc.filter(gr_complex(I,Q)); float x = phase_detector(filtered_IQ,0); static const float alpha = 0.001; static const float beta = alpha * alpha / 4; d_freq = d_freq + beta * x; d_phase = mod_2pi(d_phase + d_freq + alpha * x); mpeg_packet_error_rate.py: 485526 errors out of 2165316 packets. 1679790 good packets. Error rate = 0.224 Almost working: gr_complex input = agc.scale(in[k]); gr_sincosf(d_phase,a_sin,a_cos); gr_complex IQ = input * gr_complex(a_cos,-a_sin); out[k] = IQ.real(); gr_complex filtered_IQ = afc.filter(gr_complex(I,Q)); float x = phase_detector(filtered_IQ,0); static const float alpha = 0.001; static const float beta = alpha * alpha / 4; d_freq = d_freq + beta * x; d_phase = mod_2pi(d_phase + d_freq + alpha * x); mpeg_packet_error_rate.py: 258539 errors out of 2165280 packets. 1906741 good packets. Error rate = 0.119 Looks like a 36 missing packets, even tho the error rate is less, as the video is certainly worse in mplayer. --Chuck I don't know much about 8-VSB, but I was under the impression that it's a single sideband modulation scheme that benefits from being real only to avoid all the complex math associated with other modulation schemes. Do you know if this is true? I suppose I am just a little ignorant on the subject and looking to be enlightened. Thanks in advance. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc_cpll finally works
On Tue, 2008-05-20 at 21:00 -0400, Brian Padalino wrote: On Tue, May 20, 2008 at 8:52 PM, Charles Swiger [EMAIL PROTECTED] wrote: gr_complex IQ = input * gr_complex(a_cos,-a_sin); which would be necessary to handle negative frequencies I think. I don't know much about 8-VSB, but I was under the impression that it's a single sideband modulation scheme that benefits from being real only to avoid all the complex math associated with other modulation schemes. The issue turned out to be jiggering the numbers that say I strongly suggest that you not mess with these... * by .707 for the bit timing loop worked ;) We want a complex pll so it can take data directly from the usrp centered on DC, w/o having to mix it up to 5.75e6 and converting to real for the old fpll, which was just a trick to look like the old mc4020 adc boards. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc_cpll finally works
On Tue, May 20, 2008 at 9:38 PM, Charles Swiger [EMAIL PROTECTED] wrote: The issue turned out to be jiggering the numbers that say I strongly suggest that you not mess with these... * by .707 for the bit timing loop worked ;) We want a complex pll so it can take data directly from the usrp centered on DC, w/o having to mix it up to 5.75e6 and converting to real for the old fpll, which was just a trick to look like the old mc4020 adc boards. Sorry, Chuck. I am still not sure I understand the whole deal. I am not even sure how a PLL is being used since it's all AM and there's no real phase information being transmitted - is there? I was starting to read this: http://www.broadcast.net/~sbe1/8vsb/8vsb.htm And it just made me more confused as to what you're trying to accomplish using complex operations on a signal where the lower sideband has been filtered away. Any more help? Thanks, Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc_cpll finally works
On Tue, May 20, 2008 at 09:38:21PM -0400, Charles Swiger wrote: On Tue, 2008-05-20 at 21:00 -0400, Brian Padalino wrote: On Tue, May 20, 2008 at 8:52 PM, Charles Swiger [EMAIL PROTECTED] wrote: gr_complex IQ = input * gr_complex(a_cos,-a_sin); which would be necessary to handle negative frequencies I think. I don't know much about 8-VSB, but I was under the impression that it's a single sideband modulation scheme that benefits from being real only to avoid all the complex math associated with other modulation schemes. The issue turned out to be jiggering the numbers that say I strongly suggest that you not mess with these... * by .707 for the bit timing loop worked ;) We want a complex pll so it can take data directly from the usrp centered on DC, w/o having to mix it up to 5.75e6 and converting to real for the old fpll, which was just a trick to look like the old mc4020 adc boards. --Chuck Cool! Glad to hear that it's working. While you're at it, can you have it work with a sample rate of 8 MHz? As I recall, you're currently using something like 6.1 or such, which seems a bit narrow, given the roll off on the edges. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
