The Internet of Things is terrible when it’s your toaster. The real fun happens when you have hundreds or thousands of sensors sending data back to a base station every day. That requires low power, and that means LPWAN, the Low Power Wide Area Network.
There are a lot of options for LPWAN, but few are a perfect fit. LoRa is one of the rare exceptions, offering years of operation on a single AA cell, and range measured in miles. Layers two and three of LoRa are available as public documentation, but until now layer one has been patented and proprietary. At the GNU Radio Conference, [Matt Knight] gave a talk on reverse engineering the LoRa PHY with a software defined radio. Now, LoRa is open to everyone, and anyone can decode the chirps transmitted from these tiny, low power devices.
If you are a radio enthusiast it is very likely that you will own at least one software defined radio. With the entry point into the world of SDRs starting with the ultra-cheap RTL2382 based USB receiver sticks originally designed for digital TV, it’s a technology that passed long ago into the impulse purchase bracket.
If you are not a radio enthusiast, or not even a Hackaday reader, you may not have heard of SDR technology. Even the humblest up-to-date radio or TV may well contain it somewhere within its silicon, but at the user interface it will still resemble the device you would have had in the 1950s: analogue tuning, or a channel-flipper.
It is interesting to see an attempt to market a consumer device that is unashamedly an SDR, indeed that is its unique selling point. The Titus II SDR bills itself as the “World’s First Consumer Ready SDR Package”, and is based around an Android tablet mated with a 100 kHz to 2 GHz SDR tuner and a pair of speakers in a portable radio styled case. It will support all modes including digital broadcasting through software plugins, and there will be an open plugin API for developers. They are taking pre-orders, and claim that the launch price will be under $100.
It sounds like an exciting product, after all who wouldn’t want a radio with those capabilities at that price! However it leaves us wondering whether the price point is just a little too ambitious for the hardware in question, and we’ll reluctantly say we’ll believe it when we see real devices on the market. A $100 consumer price doesn’t get you much in the tablet world, and that is from high-volume Chinese manufacturing without the extra cost of the SDR hardware and the overhead of smaller volume from a niche product. There are pictures online of real prototypes at trade shows, but we’d like to see a website with fewer renders and more hard plastic.
There is another angle to this device that might interest Hackaday readers though. It should remind anyone that building one yourself is hardly a difficult task. Take an RTL2382 stick with or without the HF modification, plug it into a tablet with an OTG cable, install an app like SDR Touch, and away you go. 3D print your own case and speaker surrounds as you see fit, and post the result on hackaday.io.
The arrival of affordable software defined radio technologies over the last couple of decades has completely changed the way that radio amateurs and other radio enthusiasts approach the airwaves. There’s a minor problem with most software defined receivers though, being by their nature software driven they will usually rely on a host computer for their interface. Thus the experience is one of clicking mouse buttons or using keyboard shortcuts rather than the mechanical analogue dial interfaces that provided easy control of older radios.
This is a problem that has been addressed by [Jon Hudson, G4ABQ], with one of his SDRplay receivers. He’s mounted it and its control PC in the chassis of a very aged and non-functional Marconi CR100 communication receiver, and given it a control interface that only uses the Marconi’s front panel controls (YouTube link). A rotary encoder has been grafted onto the Marconi tuning capacitor with what looks like some Meccano, and in turn that feeds an Arduino which behaves as a keyboard for the benefit of the PC. Some extra buttons have been added for mode selection, spectrum zoom and shift, and care appears to have been taken to give their labels a period feel. Arduino code came courtesy of [Mike Ladd, KD2KOG]. The result is a very controllable SDR receiver, albeit one in a rather large case.
If you are interested in the project then we are told that it will be on the RS stand at Electronica in Munich next week, meanwhile we’ve put the video below the break.
If you want to really understand a technology, and if you’re like us, you’ll need to re-build it yourself. It’s one thing to say that you understand (analog) broadcast TV by reading up on Wikipedia, or even by looking at scope traces. But when you’ve written a flow graph that successfully transmits a test image to a normal TV using just a software-defined radio, you can pretty easily say that you’ve mastered the topic.
[Marble] wrote his flow for PAL, but it should be fairly easy to modify it to work with NTSC if you’re living in the US or Japan. Sending black and white is “easy” but to transmit a full color image, you’ll need to read up on color spaces. Check out [marble]’s project log.
Hackaday has another hacker who’s interested in broadcasting to dinosaur TVs: [CNLohr]. Check out his virtuoso builds for the ATtiny and for the ESP8266.
(Yes, the headline image is one of his earlier trials with black and white from Wikipedia — we just like the look.)
As we’ve mentioned previously, the integrity of your vehicle in an era where even your car can have a data connection could be a dubious bet at best. Speaking to these concerns, a soon-to-be published paper (PDF) out of the University of Birmingham in the UK, states that virtually every Volkswagen sold since 1995 can be hacked and unlocked by cloning the vehicle’s keyfob via an Arduino and software defined radio (SDR).
The research team, led by [Flavio Garcia], have described two main vulnerabilities: the first requires combining a cyrptographic key from the vehicle with the signal from the owner’s fob to grant access, while the second takes advantage of the virtually ancient HiTag2 security system that was implemented in the 1990s. The former affects up to 100 million vehicles across the Volkswagen line, while the latter will work on models from Citroen, Peugeot, Opel, Nissan, Alfa Romero, Fiat, Mitsubishi and Ford.
If you are someone whose interests lie in the field of RF, you won’t need telling about the endless field of new possibilities opened up by the advent of affordable software defined radio technology. If you are a designer or constructor it might be tempting to believe that these radios could reduce some of the problems facing an RF design engineer. After all, that tricky signal processing work has been moved into code, so the RF engineer’s only remaining job should be to fill the not-so-huge gap between antenna and ADC or DAC.
In some cases this is true. If you are designing an SDR front end for a relatively narrow band of frequencies, perhaps a single frequency allocation such as an amateur band, the challenges are largely the same as those you’d find in the front end of a traditional radio. The simplest SDRs are thus well within the abilities of a home constructor, for example converting a below-100kHz-wide segment of radio spectrum to the below-100kHz baseband audio bandwidth of a decent quality computer sound card which serves as both ADC and DAC. You will only need to design one set of not-very-wide filters, and the integrated circuits you’ll use will not be particularly exotic.
But what happens if the SDR you are designing is not a simple narrow-band device? [Chris Testa, KD2BMH] delivered a talk at this year’s Dayton Hamvention looking at some of the mistakes he made and pitfalls he encountered over the last few years of work on his 50MHz to 1GHz-bandwidth Whitebox handheld SDR project. It’s not a FoTW in the traditional sense in that it is not a single ignominious fail, instead it is a candid and fascinating examination of so many of the wrong turnings a would-be RF engineer can make.
The video of his talk can be found below the break, courtesy of Ham Radio Now. [Chris]’s talk is part of a longer presentation after [Bruce Perens, K6BP] who some of you may recognise from his activities when he’s not talking about digital voice and SDRs. We’re jumping in at about the 34 minute mark to catch [Chris], but [Bruce]’s talk is almost worth an article in itself..
[Jason Holt] wrote in to tell about of the release of his PRUDAQ project. It’s a dual-channel 10-bit ADC cape that ties into the BeagleBone’s Programmable Realtime Units (PRUs) to shuttle through up to as much as 20 megasamples per second for each channel. That’s a lot of bandwidth!
The trick is reading the ADC out with the PRUs, which are essentially a little bit of programmable logic that’s built on to the board. With a bit of PRU code, the data can be shuttled out of the ADC and into the BeagleBone’s memory about as fast as you could wish. Indeed, it’s too fast for the demo code that [Jason] wrote, which can’t even access the RAM that fast. Instead, you’ll want to use custom kernel drivers from the BeagleLogic project (that we’ve covered here before).
But even then, if you don’t want to process the data onboard, you’ve got to get it out somehow. 100 mbit Ethernet gets you 11.2 megabytes per second, and a cherry-picked flash drive can save something like 14-18 megabytes per second. But the two 10-bit ADCs, running full-bore at 20 megasamples per second each, produces something like 50-80 megabytes per second. Point is, PRUDAQ is producing a ton of data.
So what is this cape useful for? It’s limited to the two-volt input range of the ADCs — you’ll need to precondition signals for use as a general-purpose oscilloscope. You can also multiplex the ADCs, allowing for eight inputs, but of course not at exactly the same time. But two channels at high bandwidth would make a great backend for a custom SDR setup, for instance. Getting this much ADC bandwidth into a single-board computer is an awesome trick that used to cost thousands of dollars.
We asked [Jason] why he built it, and he said he can’t tell us. It’s a Google Research project, so let the wild conjecture-fest begin!