Slashdot Mirror

It may be easier than you think.

With all the privacy concerns surrounding RFID, it would be nice to have an RFID scanner that covers more than the dinky 125Khz-ish range that you see used in most hobby kits for home automation. Some kits support 13.56Mhz too, which is what I hear the new passports will use, but there doesn't seem to be much hardware available for the 800-1000Mhz range. Also, what is available isn't as programmable as GNU Radio, which is important for working with RFID tags that use less common or proprietary signalling standards.

The 800-1000Mhz Ultra High Frequency range is important because such tags are currently being used in vehicle tires (@ 915Mhz) and toll booth tags (like ez-pass), and it would be interesting in finding out just what else. They can be read from a distance of a few meters at even 150+ mph speeds.

It's funny this \. article came out today because I was just researching GNU Radio + USRP for this purpose and see that a new transciever daughterboard will be coming out that supports the RFID UHF range. I can't afford it, but hope someone will write the necessary signal processing routines to use RFID with this daughterboard and report back what they find and where.

The link below announces an upcoming 800-1000Mhz transciever daughterboard for the USRP -
http://comsec.com/wiki?UniversalSoftwareRadioPerip heral

Also if someone knows a cheaper than ~$700 way to pull off reading UHF RFID tags, speak up.

It has been on the market since Nov. 2004.

http://www.comsec.com/wiki?UsrpProgress

C'mon, let me just suck in the whole band from 88-108MHz and separate the stations in software.

Limiting the use of any part of the spectrum to radios that can be built "made by the user" seems wrong. (What does this mean, anyway? It isn't like folks are building their own tubes (mostly) or growing their own transistors. By any reasonable definition I can think of, our applications software atop the USRP we're using for a lot of work constitutes "making a radio", even though there's no soldering at all.)

Right now, most of our transmission work is in the "amateur 802.11" band down at channel 1. Being able to do 802.11-style DSSS at reasonable power levels is quite nice, but we'd like to do exotic modulation and work on bands with better propagation. Right now we can't.

There are undoubtedly parts of the country where a few of the bands are crowded. In Oregon, they're hardly overutilized. In any case, digital modulation uses the spectrum better, and should help relieve whatever overcrowding exists.

As to the relatively silly and pointless tasks you mention, yes. As I said earlier, I could certainly do both of them. I don't see why I should be required to, though. Who is it helping?

In 2005 you can chatter with your friends in Istanbul or Sao Paolo by voice quite nicely, through the twin miracles of cheap long distance cellphones and the Internet. Let the amateur bands be used for more interesting things.

You have a very good point, I think this law was very poorly thought out. HDTV's broadcast flag is just an extra bit, it is ignored by all current HDTV equipment. You don't even need an HDTV tuner card to recieve HDTV. The folks over at GNU Radio have gotten a programmable radio to recieve HDTV. Does this law say anything about non-HDTV equipment that happens to be able to recieve HDTV signals? If not then why not just sell these HDTV cards as A/D converters.

Nice rant -- can't wait to hear your conniption when SDR (Software Defined Radio) becomes mainstream.

This thing can recieve HDtv - so you can ignore the broadcast flag. That obviously makes it a terrorist tool.

Parent is ripped from http://comsec.com/wiki?SoftwareRadio

Is it really so hard to use tags?

Software radio or SDR - an intresting subject where mathematical formulas become radio.

See for a high level overview.

Good reading is Understanding digital Signal processing by Richard G. Lyons. Prentice Hall, 1st ed: ISBN 0201634678 (amazon.com, search). 2nd ed: ISBN 0-13-108989-7 (amazon.com, search)

VanuBose 's company Vanu Technology demonstrated a software radio based on an iPAQ with a digital radio "backpack", in May 2003. Here are some links:

Slashdot article

Linuxdevices.com

Vanu.com

Vanu.com

Here's a note on the future of software defined radio

Several relevant pointers available here

I don't know what's happened in the past year or so...

Last edited September 17, 2004 11:16

If anyone's seen the GNU software radio to do HDTV it's neat http://comsec.com/wiki?HowtoHdTv. Only $1000 worth of hardware though :(

Really? What about these projects then:

GPS and GnuRadio

and

OpenSourceGPS

The latter claims:

"The receiver requires at a minimum a 100 MHz 486 IBM PC with 640k RAM."

So it seems to be possible. Someone posted the GPSTk link to the GnuRadio mailing list with the hope of eventually getting GnuRadio the ability to do advanced processing of GPS signals.

I'm not a GPS expert... am I missing something here?

I'll shut up after this, promise. :-)

Multisecond RTT doesn't happen on anything but GPRS

I've seen it far too often on congested wifi networks. you easily get into a congested state with a crowded AP that forces lots of client waits for the DCF (i.e DIFS + padding, each in turn) and also induces lots of retransmission at the physical level due to collision with so many clients trying to talk to the same AP. Low power clients associated at the 1 or 2 Mbps rates drive this contention over the DCF even higher, severely punishing everyone associated.

The big conference venues are notoriously bad about this, as you often end up with 10-20+ people associated with a single access point. That is just too many, and the 802.11 MAC was never meant to handle that kind of load efficiently. It is a pretty good solution for the general case that simply can't cover all the edge cases (long shots, high client loads, noisy RF environments).

This type of situation results in really weird ping times, for example. I've seen fluctuations myself that go from 80ms, 120ms to 3s!, 2s!, etc. then back down to a few score milliseconds. That is the 802.11 MAC trying to cope with scenario's it was never designed to encounter.

I mentioned software radios in the first post because having access to timing and congestion control in the MAC would allow mesh boxes, clients, and AP's to make very significant performance enhancements for situations where they were needed. Why be forced to use a static, inflexible, proprietary hardware layer when you can have the open flexibility associated with software radio? (It's coming, just not soon enough :-) There are also extensions to the ad-hoc routing protocols (like passive monitor of route info between other clients in DSR) that could be supported if only the hardware was open enough to do so.

I don't want to bitch too much; we have come a long way from sub-megabit data via FHSS over 900Mhz. I just want the really good stuff to hurry up and get here already so that things like mesh networks, low latency/loss voice over IP, and highly available multipath/redundant network configurations can be enjoyed to their full potential. (software radio + multiple input / multiple output + intelligent network stacks that can handle a diverse and volatile network environment). ... and a pony!

Gratuitous links:
congestion problems at TechEd conference

congestion melt down at CeBIT

GNU Radio's software defined radio (SDR)

software defined radio on $2,000 of 'roids [it's a dev kit, but would work very well for almost any kind of project]

If my understand is correct, some of the guys from the GNU Radio Project have developed a USB based software radio device that works with in linux. It is called the Universal Software Radio Peripheral. I think the first prototypes have shipped. The cost is pretty close to your price range. You can see it in action running an oscope program here. And of course it can be extended to do many more exciting things.

If my understand is correct, some of the guys from the GNU Radio Project have developed a USB based software radio device that works with in linux. It is called the Universal Software Radio Peripheral. I think the first prototypes have shipped. The cost is pretty close to your price range. You can see it in action running an oscope program here. And of course it can be extended to do many more exciting things.

Uncompressed HDTV uses a lot of bandwidth. Compressed HDTV does not. Assuming 24 bits per pixel, a 1080i signal would require nearly 200MBytes per second (and even more if whatever device you're talking to only does 32bpp), which goes far beyond the standard 133MByte/s of a normal PCI bus. However, it's well within the domain of a 64-bit PCI66 slot or an AGP 1x slot (both of which operate at 533MByte/s, if memory serves).

A full-bandwidth ATSC stream can carry nearly 20 Mbit/s of data, which translates to around 2.5MByte/s.

The GNU Radio people weren't really doing either of those things -- they did a really raw capture of that ~20Mbit/s stream (though with error correction added in, an ATSC broadcast runs more like 25-30Mbit/s). With the sampling hardware they used, it added up to something around 40MByte/s of data being captured, according to their How to HDTV page.

CQiNet - Open Source implementation of Voice over IP (VoIP) software specifically for Ham Radio. Currently there are three popular VoIP packages used by Ham Radio operators, IRLP, ILink and EchoLink. Since none of these packages are open source it is difficult to contribute to the their development and learn from them by studying their source code. Let's face it for many of us Ham Radio is more about playing with technology than it is about yacking on the radio or Internet. (Hmmm... maybe some folks on Slashdot could learn something....)

Hamsoft - A great HAM/Linux database. (not to be confused with GNU/Linux)

TAPR! - These geeks will whoop yer ass in a second! A lot of them are commited to open source. They actually help fund HARDWARE projects (we could learn something). Check out their LINUX sig.

Flex-Radio - An open source software defined radio!

GnuRadio - Signal Processing in oepn source software

I ask a simple question in the hopes of stimulating some debate. You people are so closed minded. Well, you live an learn. You won't be hearing more from me on slashdot after this post. (are those cheers I hear?!)

Thank you to everyone who answered with reasonable answers either for or against. Before I go I'll answer some of the points people raised.

Land Lines & Infrastructure

I am talking about a wireless network with no central infrastructure, no land lines, just peer devices.

The initial costs of a centralised netowrk are huge. Do you think that operators are going to continue to roll out huge networks after the fiasco that was 3G? (and regular broadband/cable TV in many areas). I think we'll wait a long time before we see those kind of investment by any central organisation again.

The total costs of a distributed network are even more huge. However the cost is spread among whoever wants to pay for their devices. See that FAX story on slashdot from a while ago for an analogy.

Free as in ... peer?

I don't want the infrastructure or services I need for free.

I am not a freeloader or pirate. I am quite willing to pay for my equipment. I just want it to be subscriptionless. The cost of the network is built into the the device and whatever it costs in electricity (at least until I fine tune the cold fusion process & matter replicator that I've been working on that is). If this means $50bn devices as someone mentioned, then so be it ;) Technology prices come down all the time though. How much is an ethernet card today compared to when it first arrived?

Let me ask a question, do you pay a subscription for a bluetooth PAN? For WiFi in your home? Why not? Are you ripping someone off by not doing so? Why not extend the metaphor to communities, or towns, or cities, or the world? I am quite aware that there are problems of scale and many others which was why I asked the question. I wanted to see what you all thought could be potential solutions. Seems you'd mostly prefer to take cheap shots or try to look cool or whatever.

I don't expect to connect to existing networks like the internet, GSM, POTS etc. for free. They are largely owned by private operators and if you want to connect to them they are going to charge you for that privelege. However if you have a no-subscription network out there then maybe web sites, and all those other services that appear on communication networks would start to appear on it, or even migrate exclusively to it.

Spectrum saturation & interference

I don't know enough about about spectrum to answer this myself, so I'll point you at this GnuRadio: MeshNetworks and also this slashdot story The Myth of Radio Spectrum Interference which was featured on slashdot a while ago, and ask it it just BS? They seem to me to be saying that the more nodes in a wireless network, the greater the bandwidth.

Battery life:

This is a problem that is going to take a long time to solve unless there are some major breakthroughs in battery technology. I have no suggestions.

Routing:

Difficult? For sure, but impossible?

You don't have to use IP you know. It's not the internet. I think that it is going to be possible for devices to route to others. I'm not saying it's easy but surely not impossible to at least get a "good enough" algorighm?

I recall reading somewhere about a routing algorithm that was modeled on ant's behaviour to achieve good enough shortest path finding. Is there no scope within this or other areas of research to make advances? Here's a link to one similar paper I found now just to proove I'm not hallucinating: http://www.computer.org/proceedings/icppw/1680/168 00079abs.htm . Use g

Besides which, GSM mobile phones typically use they're processing power to allow them to do fast frequency hopping, etc.