I think if they had a wider bandwidth ADC they could get rid of the analog Doppler filter. Eventually the oversampling in the ADC would give them back the dynamic range they need. They used about as basic of an A/D card as it gets. The BOM is way less than $200k I'm sure. The boards for the antennas probably aren't cheap due to their size, and I don't know if they are FR-4 or Rogers. They'd probably cost $2k or so on a 1 week turnaround, probably less. The RF components and cables can be scavenged off eBay if you have time, or bought from mini-circuits and similar suppliers, the latter will run another $5k tops I'd think. The A/D board is $1.2k. Mechanicals will run another $2k or so. So in a pinch you can do it for $10k in hardware less PC. If you have time to do your own board layout and circuit design, and have time to use long leadtime PCB suppliers, you can get an even better signal chain for way less money -- I think $2k of electronics per system for a run of 10 is not unimaginable. You could put the RF signal chain on a PC board and use cheaper components than having to wire everything up from enclosed modules, as they perhaps did.
They use very little bandwidth between ADC/DAC and PC, this could be easily running via Ethernet. With a proper choice of CPU they wouldn't even need an FPGA. I think that their current design's front-end digital logic would fit entirely on a Parallax Propeller attached to ADC, DAC and switches, with external Ethernet interface attached to it to stream the raw data to the PC. The Prop is too slow to do the DSP of course, but for sequencing, waveform playback and acquisition it'd work just fine. I think that a single board with ADC, CPU, Ethernet, and all of the RF signal chain could be had for $1k total in qty 1, and none of it would be very exotic at all - not a single BGA to be soldered, I'd think.
They had to trade off time for money to get this done without wasting a couple years. For proofs-of-concept it's the way to go. The design leaves a lot of room for improvement, and that's what I really like about it. If one only had enough time to play with all that! The article is detailed enough that with consulting some of the references you could replicate the whole system without too much sweat. I really like their approach to signal processing on the PC, controlling the show from Python. Very slick.
This is not a multi-billion dollar project. With a bit of resourcefullness, you could do it yourself for under $2k in hardware, assuming you've got a good PC and a decently instrumented electronics workbench. There's no magic "millions of dollars worth of noise cancellation equipment" -- it exists in silly movies only. Either you are above or below noise floor, and even if you're below you can employ averaging to trade off bandwidth (in the sense of frame rate) for SNR improvement. Heck, they do a lot multiplexing and use a really simple data acquisition setup. If they'd get each antenna to have its own oscillator and radiate at a different frequency, they could run all the antennas at the same time, improving their SNR by quite a bit because they'd have more data to average from.
Hmm, I've re-read the article and it does seem like they use a filter to get rid of some of the wall echoes. They say it's their way of doing range gate, and I only imagine it's because the transmitted pulse is frequency-chirped. The earlier reflections will have different frequency than the later ones, so they essentially shift a time domain problem into frequency domain by sending out a time-dependent frequency signal.
There are no frequency differences from the echos from stationary objects. They use beamforming/SAR techniques to get a stationary antenna to form a 2D image in downrange/crossrange coordinates (far/near vs sideways). There's no imaging along the top-bottom direction, although that's not a big issue: all they'd need is to replicate their linear antenna into a 2D antenna. The echo from the wall is still there, but they simply subtract a reference radar image from current image. If you stand very still, the radar will be blind to you:) The wall echo is not useless: it lets you use the radar for mapping, where you need static references like walls to stitch the images together.
While some of your objections against such technology's possible uses are understandable, the technology is not to blame. What we already have: miniature cameras and insane U.S. building standards will let anyone spy on anyone else anyway, right now, with much simpler tech.
For non-U.S. dwellers: a typical recent U.S. single-family residential building's wall consists of, going inside out: paint, drywall, plastic vapor block, vertical wood studs with fiberglass insulation between them, foam board "sheeting", home wrap membrane, plastic siding. Siding is in horizontal sections and is easy to snap off and snap back on. To spy on someone: 1. pull up a piece of siding, 2. use fingers/knife to go through home wrap and board, 3. push fiberglass insulation aside, scrape some drywall from outside to make it thinner, 4. drill a small hole, place a wireless camera with power source against the recess you've made in drywall 5. put insulation back around the camera to hold it in place 6. snap siding back in
With experience, I imagine it'd be a one minute job, and if the hole in the drywall is strategically located, no one will notice. Who the heck needs advanced through-the-concrete radar...
Most homes will have simple variations upon this theme: aluminum siding instead of vinyl on older homes, lack of insulation in the wall cavities, sometimes the exterior sheeting is OSB (oriented strand board) -- you can punch a hole in it with a screwdriver:)
I do agree about the "moment of truth" though. But I personally like faster architectures -- XMOS XC-1 running at 125 MIPS per thread with 4 threads running in parallel lets you do some spectacular things purely in software. Say running USB 2.0 at maximum speed, and running 100mbit ethernet.
Parallax Propeller I pushes 20 MIPS per cog (thread), with 8 threads running that gives 160 MIPS total, but it doesn't have a multiplier so I couldn't use it for my number crunching. It lets you emulate Z80 in a single thread, people are running CP/M on it, in a single chip.
Huh? Using hardware SPI ports, I'm very comfortably acquiring 16 bit data at 80ks/s using an 8 bit CPU that runs at about 8 MIPS. And that requires pushing 3 bytes both ways to and from the ADC, using a rather roundabout way of getting DMA to handle that. Even if it run on interrupts, it'd still be "reasonable": about 2.5MIPS would be lost for interrupt handling. The SPI in this application pushes an aggregate of 3.84Mbits/s (half of it each way).
It'd take a fairly crippled chip to require bit-banging anything. With any decent 8 bit CPU, SPI is handled in hardware, perhaps even with hardware FIFOs that are more than a byte deep.
I've used a souped-up 12 bit PIC (as 8 bits as it gets!) -- the Parallax SX48 to not only bit-bang to two 16 bit ADCs and DACs at 32 ks/s, but I was also doing an adaptive FIR filter. Everything ran without interrupts, in straight-line code. All I had for FIRs was shift-and-add. I used an external RAM chip for a buffer because internal RAM was a whoopee-de-doo 256 bytes:)
That's true, but not necessarily applicable. There's this seemingly large group of people who forgot what the difference is between saying generally offensive things vs. being racist. This group will classify anything as racist if it is both offensive and targeted at someone of a different race than the speaker's. As much as I'm anti-racism, I'm disgusted by the above mentioned group of people.
The RAM in the CPU is acting pretty much as the cache would in a larger CPU. Bulk data is stored off-chip -- either in the display's own framebuffer, or on the SD card.
It probably could play MP3s as follows: 1. Tweak framework design to allow a background task. 2. Pre-render MP3s in the background and store the decoder output back onto the SD card. This may need ugly hacks like storing some tables at runtime in the built-in FLASH or EEPROM since RAM is short, but it'd work in principle -- probably at 1/10th of native speed or somesuch. 3. Play pre-rendered MP3s in the foreground.
I'd think that it's not a problem if the processor has single-cycle execution and a 16x16 single-cycle multiplier. You'd also need a fast clock (50+MHz).
It should be perhaps pointed out that this algorithm's lower bound shifts quite dramatically depending on the number of digits sought. As long as it fits machine precision, it's Omega(N) since addition doesn't care how many digits of the addends are "used up". Once N gets large, the cost approaches N^2, and that's what counts in asymptotic complexity...
Let's see if that would work out. There are algorithms out there where you draw a circle doing nothing but additions/subtractions. It's "reasonably" easy to accumulate the length of such a circular octant while updating the x/y coordinates - we don't have to accumulate the bitmap at all, just count the pixels. To get the length accurate enough, we'd need on the order of N pixels on the circumference, so that means about that many updates through the loop. Since the loop does additions, the cost of an iteration is also N. That means O(N^2) performance. That won't work. Alas, it is possible to get the result in the right base without doing further divisions (ratio of circumference to radius): we simply set the radius to a suitable number, such that division is just shifting the fractional point around, in whatever base we chose.
The base is where the problem is at. You can get arbitrary digits of pi calculated in base 16. But to do base conversion to base 10, you need to know all of the previous digits. So you can only use the spigot to give you hex digits of pi. But the pi, as we have it, is probably in base 10 or some other base that's easy t convert to base 10 (say base 10^7). Doing base conversions from base 10 to base 16 on the existing 10 trillion digit result is not trivial either: it might take more time than calculating the value of pi in the first place.
I loved Clarke's way of saying big things with small, unassuming words. "Overhead, without any fuss, the stars were going out.". The effect of throwing a sledgehammer at something, achieved with an overcooked pea. Yummy.
There is quite an ingenuous way of getting a small (<10mm^2) optical receiver to be insensitive to droplets of water, splotches of mud, etc. All you do is place it inside a larger dome;)
The remote for my iPod dock works if you point it anywhere in the same room. It also works very well if you open the door, go to the hallway, and point it almost anywhere in the hallway, as long as you're not too close to the wall. Heck, my desktop lamp, pointed straight at the table, illuminates almost the whole room. How about that!
</sarcasm>
Again, jamming RF is trivial with off-the-shelf components. Jamming optical is not trivial at all.
Yeah, decently sized ships definitely have an inertial reference platform, at the minimum for heading (gyrocompass). This allows for rudimentary dead reckoning in the nav computer, when you assume known current speed and heading.
The fact that they applied it to a "life critical" system is mirrors and smoke. It's a completely useless pretense, it did not affect their approach. They got some off-the-shelf RF communication modules, set them for either fixed-slot TDMA or random-slot TDMA, used a fairly "new" modeling system to show that the performance matches theoretical predictions known for decades, then wrapped it all up in a safety critical burrito. It's the filling that counts, and the filling was hot 50 years ago. Seriously. This is nothing new, and their engineering sucks donkey balls for the purpose -- they ignore almost everything that counts in such an implementation. They ignore reliability of the medium (interference), they ignore reliability of the RF modules, of power sources, of whatever sensors and actuators they use -- it's an academic exercise that's good as a tutorial, but it doesn't belong on first page of Slashot. I took a reliability engineering class a while ago, and I'd be laughed out of the classroom if I presented their work as a final paper. The modeling part of paper's contents would be a reasonable early homework assignment in a graduate level class on stochastic network modeling. Their experimental results are a single lab assignment for such a class. That's about it. It a tutorial exercise, it's not useless, but as a conference paper it's a joke.
This is hyperbole. You have to read the article. The time scale is nothing special and nothing new. They use off-the-shelf RF modules, configured per their appnote/datasheet. A typical GSM cellphone connection on the same network has fixed end-to-end delay that is well under 150ms. "Well" as in it can he half an order of magnitude less. Heck, they could have gotten their stuff to work similarly well, in controlled conditions as they have, by using two GPRS modems. It'd at least require some more effort to produce even a simplified model for a GPRS-based system. They cut as many corners as possible.
The project is not ambitious at all. Their main "contributions" are:
0. A poor-mans tutorial of a new modeling system. 1. Basic equations that model networks with packet collisions (they never reproduce them, but oh well), known for decades, provide same numbers as their model. 2. The off-the-shelf hardware works, in idealized conditions, about as well as the model predicts, and in line with how the manufacturer has designed it to work in the first place. No shit, Sherlock? 3....
There's no profit, there's no new results, there's nothing there. Engineering-wise, their approach is silly from about every angle because they miss everything that would be important in a real-life implementation. They are hung up on TDMA and time slots like it was a God-given thing that such a system must use such a transmission scheme.
They got a bunch of off-the-shelf hardware, got it to work pretty much as the application note says, and they confirm nothing new, and nothing exciting. I was going to say that this should have never gotten accepted for publication, but then it was in conference proceedings, so perhaps you get to publish just because you want to show up? I guess IEEE WoWMoM symposium is a joke where anyone who gets off-the-shelf stuff to work per application note and adds "in a realtime this-or-that" gets to have their say. It's sad on so many levels.
Their article is decent if it were destined for night-time reading like Circuit Cellar, not an IEEE conference.
I guess the real reason the article reads like a solid WTF is that they are, supposedly, computer scientists with no experience in RF, controls, or safety-critical system design.
If anything, the system should have used optical transmission. It'd be fairly interference- and jam-proof, had they decided to use a modulated transmission -- modulated using a carrier and a PRN code so that multiple bikes in vicinity would not interfere with each other. GPS satellites do transmit at the same frequency, after all, and there's no interference.
Due to small distance between the handlebar and the actuator/receiver, you'd need a fairly powerful laser system to do any sort of large-area jamming, and any small-scale jamming would need tracking -- of course it can be retrofitted to existing, say, tracking camera systems they have on police choppers. Yet, if the transmission was done using two layers of PRN: PRN-driven frequency hopping for the optical subcarrier *and* a digital PRN code, then it could be pretty much jam-proof unless you knew the generator settings. Heck, it the PRN could come from a cryptographically secure generator, where it's "nigh impossible" to know the future code sequence without physically hacking into the box.
I don't think I would want to use any sort of a wireless brake system that uses radio, especially an unlicensed ISM band. It's a fairly preposterous idea. You could trivially swamp the receivers in bikes on a whole block using off-the-shelf radio gear with a concealed antenna. With an optical system, it's line-of-sight. A tinfoil umbrella is all you need to shield it from airborne jamming;)
Slashdot Mirror
I think if they had a wider bandwidth ADC they could get rid of the analog Doppler filter. Eventually the oversampling in the ADC would give them back the dynamic range they need. They used about as basic of an A/D card as it gets. The BOM is way less than $200k I'm sure. The boards for the antennas probably aren't cheap due to their size, and I don't know if they are FR-4 or Rogers. They'd probably cost $2k or so on a 1 week turnaround, probably less. The RF components and cables can be scavenged off eBay if you have time, or bought from mini-circuits and similar suppliers, the latter will run another $5k tops I'd think. The A/D board is $1.2k. Mechanicals will run another $2k or so. So in a pinch you can do it for $10k in hardware less PC. If you have time to do your own board layout and circuit design, and have time to use long leadtime PCB suppliers, you can get an even better signal chain for way less money -- I think $2k of electronics per system for a run of 10 is not unimaginable. You could put the RF signal chain on a PC board and use cheaper components than having to wire everything up from enclosed modules, as they perhaps did.
They use very little bandwidth between ADC/DAC and PC, this could be easily running via Ethernet. With a proper choice of CPU they wouldn't even need an FPGA. I think that their current design's front-end digital logic would fit entirely on a Parallax Propeller attached to ADC, DAC and switches, with external Ethernet interface attached to it to stream the raw data to the PC. The Prop is too slow to do the DSP of course, but for sequencing, waveform playback and acquisition it'd work just fine. I think that a single board with ADC, CPU, Ethernet, and all of the RF signal chain could be had for $1k total in qty 1, and none of it would be very exotic at all - not a single BGA to be soldered, I'd think.
They had to trade off time for money to get this done without wasting a couple years. For proofs-of-concept it's the way to go. The design leaves a lot of room for improvement, and that's what I really like about it. If one only had enough time to play with all that! The article is detailed enough that with consulting some of the references you could replicate the whole system without too much sweat. I really like their approach to signal processing on the PC, controlling the show from Python. Very slick.
This is not a multi-billion dollar project. With a bit of resourcefullness, you could do it yourself for under $2k in hardware, assuming you've got a good PC and a decently instrumented electronics workbench. There's no magic "millions of dollars worth of noise cancellation equipment" -- it exists in silly movies only. Either you are above or below noise floor, and even if you're below you can employ averaging to trade off bandwidth (in the sense of frame rate) for SNR improvement. Heck, they do a lot multiplexing and use a really simple data acquisition setup. If they'd get each antenna to have its own oscillator and radiate at a different frequency, they could run all the antennas at the same time, improving their SNR by quite a bit because they'd have more data to average from.
Hmm, I've re-read the article and it does seem like they use a filter to get rid of some of the wall echoes. They say it's their way of doing range gate, and I only imagine it's because the transmitted pulse is frequency-chirped. The earlier reflections will have different frequency than the later ones, so they essentially shift a time domain problem into frequency domain by sending out a time-dependent frequency signal.
There are no frequency differences from the echos from stationary objects. They use beamforming/SAR techniques to get a stationary antenna to form a 2D image in downrange/crossrange coordinates (far/near vs sideways). There's no imaging along the top-bottom direction, although that's not a big issue: all they'd need is to replicate their linear antenna into a 2D antenna. The echo from the wall is still there, but they simply subtract a reference radar image from current image. If you stand very still, the radar will be blind to you :) The wall echo is not useless: it lets you use the radar for mapping, where you need static references like walls to stitch the images together.
See page 554 in TFA. They image a guy holding a metal rod. The name of the output file in the screenshot? StarwarsKid. Yay!
While some of your objections against such technology's possible uses are understandable, the technology is not to blame. What we already have: miniature cameras and insane U.S. building standards will let anyone spy on anyone else anyway, right now, with much simpler tech.
For non-U.S. dwellers: a typical recent U.S. single-family residential building's wall consists of, going inside out: paint, drywall, plastic vapor block, vertical wood studs with fiberglass insulation between them, foam board "sheeting", home wrap membrane, plastic siding. Siding is in horizontal sections and is easy to snap off and snap back on. To spy on someone:
1. pull up a piece of siding,
2. use fingers/knife to go through home wrap and board,
3. push fiberglass insulation aside, scrape some drywall from outside to make it thinner,
4. drill a small hole, place a wireless camera with power source against the recess you've made in drywall
5. put insulation back around the camera to hold it in place
6. snap siding back in
With experience, I imagine it'd be a one minute job, and if the hole in the drywall is strategically located, no one will notice. Who the heck needs advanced through-the-concrete radar...
Most homes will have simple variations upon this theme: aluminum siding instead of vinyl on older homes, lack of insulation in the wall cavities, sometimes the exterior sheeting is OSB (oriented strand board) -- you can punch a hole in it with a screwdriver :)
I do agree about the "moment of truth" though. But I personally like faster architectures -- XMOS XC-1 running at 125 MIPS per thread with 4 threads running in parallel lets you do some spectacular things purely in software. Say running USB 2.0 at maximum speed, and running 100mbit ethernet.
Parallax Propeller I pushes 20 MIPS per cog (thread), with 8 threads running that gives 160 MIPS total, but it doesn't have a multiplier so I couldn't use it for my number crunching. It lets you emulate Z80 in a single thread, people are running CP/M on it, in a single chip.
Huh? Using hardware SPI ports, I'm very comfortably acquiring 16 bit data at 80ks/s using an 8 bit CPU that runs at about 8 MIPS. And that requires pushing 3 bytes both ways to and from the ADC, using a rather roundabout way of getting DMA to handle that. Even if it run on interrupts, it'd still be "reasonable": about 2.5MIPS would be lost for interrupt handling. The SPI in this application pushes an aggregate of 3.84Mbits/s (half of it each way).
It'd take a fairly crippled chip to require bit-banging anything. With any decent 8 bit CPU, SPI is handled in hardware, perhaps even with hardware FIFOs that are more than a byte deep.
I've used a souped-up 12 bit PIC (as 8 bits as it gets!) -- the Parallax SX48 to not only bit-bang to two 16 bit ADCs and DACs at 32 ks/s, but I was also doing an adaptive FIR filter. Everything ran without interrupts, in straight-line code. All I had for FIRs was shift-and-add. I used an external RAM chip for a buffer because internal RAM was a whoopee-de-doo 256 bytes :)
If you get baptized. You don't get baptized at birth, yaknow.
That's true, but not necessarily applicable. There's this seemingly large group of people who forgot what the difference is between saying generally offensive things vs. being racist. This group will classify anything as racist if it is both offensive and targeted at someone of a different race than the speaker's. As much as I'm anti-racism, I'm disgusted by the above mentioned group of people.
The RAM in the CPU is acting pretty much as the cache would in a larger CPU. Bulk data is stored off-chip -- either in the display's own framebuffer, or on the SD card.
It probably could play MP3s as follows:
1. Tweak framework design to allow a background task.
2. Pre-render MP3s in the background and store the decoder output back onto the SD card. This may need ugly hacks like storing some tables at runtime in the built-in FLASH or EEPROM since RAM is short, but it'd work in principle -- probably at 1/10th of native speed or somesuch.
3. Play pre-rendered MP3s in the foreground.
I'd think that it's not a problem if the processor has single-cycle execution and a 16x16 single-cycle multiplier. You'd also need a fast clock (50+MHz).
It should be perhaps pointed out that this algorithm's lower bound shifts quite dramatically depending on the number of digits sought. As long as it fits machine precision, it's Omega(N) since addition doesn't care how many digits of the addends are "used up". Once N gets large, the cost approaches N^2, and that's what counts in asymptotic complexity...
Let's see if that would work out. There are algorithms out there where you draw a circle doing nothing but additions/subtractions. It's "reasonably" easy to accumulate the length of such a circular octant while updating the x/y coordinates - we don't have to accumulate the bitmap at all, just count the pixels. To get the length accurate enough, we'd need on the order of N pixels on the circumference, so that means about that many updates through the loop. Since the loop does additions, the cost of an iteration is also N. That means O(N^2) performance. That won't work. Alas, it is possible to get the result in the right base without doing further divisions (ratio of circumference to radius): we simply set the radius to a suitable number, such that division is just shifting the fractional point around, in whatever base we chose.
The base is where the problem is at. You can get arbitrary digits of pi calculated in base 16. But to do base conversion to base 10, you need to know all of the previous digits. So you can only use the spigot to give you hex digits of pi. But the pi, as we have it, is probably in base 10 or some other base that's easy t convert to base 10 (say base 10^7). Doing base conversions from base 10 to base 16 on the existing 10 trillion digit result is not trivial either: it might take more time than calculating the value of pi in the first place.
I loved Clarke's way of saying big things with small, unassuming words. "Overhead, without any fuss, the stars were going out.". The effect of throwing a sledgehammer at something, achieved with an overcooked pea. Yummy.
Huh? You use a sun filter and you can definitely look at the Sun with a telescope.
There is quite an ingenuous way of getting a small (<10mm^2) optical receiver to be insensitive to droplets of water, splotches of mud, etc. All you do is place it inside a larger dome ;)
The remote for my iPod dock works if you point it anywhere in the same room. It also works very well if you open the door, go to the hallway, and point it almost anywhere in the hallway, as long as you're not too close to the wall. Heck, my desktop lamp, pointed straight at the table, illuminates almost the whole room. How about that!
</sarcasm>
Again, jamming RF is trivial with off-the-shelf components. Jamming optical is not trivial at all.
Yeah, decently sized ships definitely have an inertial reference platform, at the minimum for heading (gyrocompass). This allows for rudimentary dead reckoning in the nav computer, when you assume known current speed and heading.
The fact that they applied it to a "life critical" system is mirrors and smoke. It's a completely useless pretense, it did not affect their approach. They got some off-the-shelf RF communication modules, set them for either fixed-slot TDMA or random-slot TDMA, used a fairly "new" modeling system to show that the performance matches theoretical predictions known for decades, then wrapped it all up in a safety critical burrito. It's the filling that counts, and the filling was hot 50 years ago. Seriously. This is nothing new, and their engineering sucks donkey balls for the purpose -- they ignore almost everything that counts in such an implementation. They ignore reliability of the medium (interference), they ignore reliability of the RF modules, of power sources, of whatever sensors and actuators they use -- it's an academic exercise that's good as a tutorial, but it doesn't belong on first page of Slashot. I took a reliability engineering class a while ago, and I'd be laughed out of the classroom if I presented their work as a final paper. The modeling part of paper's contents would be a reasonable early homework assignment in a graduate level class on stochastic network modeling. Their experimental results are a single lab assignment for such a class. That's about it. It a tutorial exercise, it's not useless, but as a conference paper it's a joke.
This is hyperbole. You have to read the article. The time scale is nothing special and nothing new. They use off-the-shelf RF modules, configured per their appnote/datasheet. A typical GSM cellphone connection on the same network has fixed end-to-end delay that is well under 150ms. "Well" as in it can he half an order of magnitude less. Heck, they could have gotten their stuff to work similarly well, in controlled conditions as they have, by using two GPRS modems. It'd at least require some more effort to produce even a simplified model for a GPRS-based system. They cut as many corners as possible.
The project is not ambitious at all. Their main "contributions" are:
0. A poor-mans tutorial of a new modeling system. ...
1. Basic equations that model networks with packet collisions (they never reproduce them, but oh well), known for decades, provide same numbers as their model.
2. The off-the-shelf hardware works, in idealized conditions, about as well as the model predicts, and in line with how the manufacturer has designed it to work in the first place. No shit, Sherlock?
3.
There's no profit, there's no new results, there's nothing there. Engineering-wise, their approach is silly from about every angle because they miss everything that would be important in a real-life implementation. They are hung up on TDMA and time slots like it was a God-given thing that such a system must use such a transmission scheme.
They got a bunch of off-the-shelf hardware, got it to work pretty much as the application note says, and they confirm nothing new, and nothing exciting. I was going to say that this should have never gotten accepted for publication, but then it was in conference proceedings, so perhaps you get to publish just because you want to show up? I guess IEEE WoWMoM symposium is a joke where anyone who gets off-the-shelf stuff to work per application note and adds "in a realtime this-or-that" gets to have their say. It's sad on so many levels.
Their article is decent if it were destined for night-time reading like Circuit Cellar, not an IEEE conference.
I guess the real reason the article reads like a solid WTF is that they are, supposedly, computer scientists with no experience in RF, controls, or safety-critical system design.
If anything, the system should have used optical transmission. It'd be fairly interference- and jam-proof, had they decided to use a modulated transmission -- modulated using a carrier and a PRN code so that multiple bikes in vicinity would not interfere with each other. GPS satellites do transmit at the same frequency, after all, and there's no interference.
Due to small distance between the handlebar and the actuator/receiver, you'd need a fairly powerful laser system to do any sort of large-area jamming, and any small-scale jamming would need tracking -- of course it can be retrofitted to existing, say, tracking camera systems they have on police choppers. Yet, if the transmission was done using two layers of PRN: PRN-driven frequency hopping for the optical subcarrier *and* a digital PRN code, then it could be pretty much jam-proof unless you knew the generator settings. Heck, it the PRN could come from a cryptographically secure generator, where it's "nigh impossible" to know the future code sequence without physically hacking into the box.
I don't think I would want to use any sort of a wireless brake system that uses radio, especially an unlicensed ISM band. It's a fairly preposterous idea. You could trivially swamp the receivers in bikes on a whole block using off-the-shelf radio gear with a concealed antenna. With an optical system, it's line-of-sight. A tinfoil umbrella is all you need to shield it from airborne jamming ;)