SDR -- software defined radio

I found this site a while ago if anyone want to try some explore some radio stuff without any hardware:
http://www.websdr.org/
It let you connect to a bunch SDRs across the world, and gives you a realtime graph of the whole spectrum so you can find interesting signals.
You can make some really weird sounds with non-audio broadcasts, and messing with the decoding formats etc.
You can even record wavs directly in the website and download them.

2 Likes

Just spent the last few minutes getting infuriated by some ignorant and unpleasant conversation between some old brexit fellas in a town a few miles away. Aside from that - what an amazing sound source!

UPDATE:

I got my rtlsdr radio today, plugged it in, opened PD-Extended and the patch and pushed start and it worked in first go :slight_smile: On OSX as mentioned earlier.

So all good here on the radio/pd front :slight_smile:

2 Likes

Nice!

… and on OR…?
[/quote]

Yes on OSX for now. But I think Shree will compile the externals for Linux too. Actually I think they all ready exist, so I will give it a go later today, all though I dont think they will work, because on Mac I can only get the external working in PD-Extended. SO probably the same on Linux > it needs extended. But lets see what shree comes up with :slight_smile:

1 Like

Short video. Sorry I dont reallt hit much stations in this video, so it is not really right showing. Problem was I had to use soundflower to get audio into Quicktime, which ment I could not hear it while I was recording. But it worked pretty decent…

1 Like

cool,

I’ve just looked at the software… out of idle interest, and so the info is here for others interested.

looks trivial enough to build , two steps:
first compile the underlying library, as described here:

http://osmocom.org/projects/sdr/wiki/rtl-sdr#Building-the-software

then compile the pd external (assuming you want it in PD)

both have good build instructions … you’ll just need to install cmake and libusb both of which are available on pacman ( I use both for other Organelle projects, so no issues there)

good news, these are user land drivers, so no need for kernel support.
so you should be good to go :slight_smile:

2 Likes

Yes those in the link you just posted are the ones I used in the video just above. I just tried now and the external doesnt work on Organelle.

As mentioned earlier I think it is related to PD-extended. This external can, as it is now and as far as i now, only be used in PD extended, because it uses “extended” features. Which we dont have on Organelle. Or else the external has to be rewritten, I think.

did you recompile the external? the one in the pd directory will have been compiled for x86 not arm…
(generally, you can assume .pd_linux is Linux on x86, - there are better PD file naming conventions to avoid this confusion, however few developers use them!)

incorrect, the Pure Data patches use extended objects , but not the external … and you don’t have to use the PD patches to use the external, you can write your own.

so no the external does not have to be re-written, so to use you wont have to get your hands on c++ code.

I have decided that for my raspberry currently i am rigging it to work

I am coming OUT of the onboard audio that is logged into a Shoutcast server and INTO my pisound.
GLORIOUS Crytal clear sound with one of these

B000068O35_img1

:rofl:

I’m going to order one of the SDR doo-dads next week

Well, now I am talking OSX again here, cause I compare it to that, that is what I have it running on for now.

The rtlsdr~ object wont load in PD Vanilla as it is now. It works in extended. If you look in the documentation for the rtlsdr~ it says:

"Running Max version 6.1.6 and Pd-extended version 0.43.4"

It has nothing to do with the patch using extended externals for other things, it had to do with the rtlsdr~ external, the version presented on github is compiled for Extended OR it is reliying on som features which are not available in Vanilla. I can see the rtlsdr~ object has dotted line around i which means pd doesnt accept that version. Extended presents some core features that Vanilla doesnt. One I noticed is for example “create app from patch”… That is just one example of a feature available in extended which is not available in Vanilla. I am thinking that this external is probably dependant on Extended as is many other externals. If you take some of Katjaa Vetters externals, they are also mostly for extended.

Organelle doesnt run extended, it runs Vanilla right? So yeah, I am pretty sure it needs to be recompiled to work with Organelle and also to to run on Vanilla on osx. Dont know how to that yet, but I am good with OSX version for now. I can wait and see if Shree makes it at some point.

And Marc, you keep suggesting that I should “just compile it”. You know I dont know to to do that, so Cant really use that suggestion to anything. But thanks anyway…

it doesn’t load because it was compiled against 43.4 extended, but it could be compiled perfectly well against vanilla, which it what i was suggesting.
(I checked the code before I posted, its a very simple external)

1 Like

You just keep suggesting something that you know I am not capable of, “just compile it” and if you are not up for helping or giving a tip on it, please dont suggest it then.

This is the way I personally try to help:

  1. Suggest something.
  2. Give an example.

These are basic steps for helping in a positive meaningful way, And yes i know that cause I work as a teacher in a school. This works really great and inspire people. I just think very often you miss the second step, with the example and often say things like " I wouldnt do it like that" And then when one ask for an example og how you would do it… And then you dont supply any example and it just created more confusion.

as I already pointed out, both projects have good build instructions, so I assumed, if you wanted to do this, then you would read the instructions they provided, then if you had questions you would perhaps ask…
(I dont see I’m adding any value by copy/pasting things to the forum, I find it better to read from the original source)

as for the rest, my comments were to just highlight the dependency on pd-extended is purely for that ‘build’ of the external, your assumption that the external code is dependent on pd-external is incorrect. this is important because when it gets compiled for Organelle, it will not need pd-extended. (nor ‘re-written’)
this I emphasised because of your original comment:

(and then you re-iterated again in your following post)

Im merely trying to provide some technical input and also trying to ensure some technical facts are straight, not only for you, but for others who may be reading this now or in the future… if you are able (or even want) to do this or not, is up to you .

anyway, this is all a bit academic, generally Im not going to start giving step by step help for building/using using something I don’t have the device, since I cannot test the procedure to know it works.

http://www.locusonus.org/pd/

this looks promising
I’ve been testing it all morning and it’s working on OSX just fine. i see a makefile but currently it’s mac only but with raspberry/atom things could get awesome.

I’ve been running ffmpeg on my (supercharged ;)) organelle for a while, to do the video (pymovie) for OTC… its works/compiles file, but its a little cpu intensive (for organelle), not so bad if you have multiple cores, as (at least in pymovie) its run as a separate process so pushed on to a second core… on a single core machine not sure how it will perform… i guess depends if its more io bound, than cpu…

Have also been playing with this one for the last couple of days on OSX and its pretty fun :slight_smile: