DRMNA Yahoo Group had several more excellent receiver related posts:
Dennis Falk:
"...The idea here is to develop a DRM receiver that costs less than $100
(even cheaper, if at all possible) that follows certain basic concepts:
Use open-source hardware and software as much as possible, with as
little proprietary reliance as possible, and preferably with off-the-
shelf parts (to minimise expense in development).
Above all else, it should be a standalone product, as the target user
WILL NOT be the type to hack into a radio to feed off an internal IF!
Nearly everything we need IS available; it's just a matter of
assembling the parts and writing the core software needed, for the
most part.
It SHOULD be an all-mode receiver, as everything- including DRM- is
for all practical purposes, DSP. (More accurately, the OFDM transport
is DSP, with the further decoding of the actual data stream.)
Android is mentioned. In truth, it's similar to Mac OSX, in that it's
a proprietary overlay for an open Unix/Linux system-- Go STRAIGHT to
embedded Linux, avoid corporate Google! :)
(The new Boxee Box, which is using an Intel ATOM, is based on
embedded Linux.)
I'm wary of using Intel's chips, because I would prefer an open
architecture, one that would survive its sources, not just that it's
plentiful. I'd look into what chips are being used in cheap pocket
multimedia players, as alot of these DO use open architecture, and
because they're both POWERFUL enough and CHEAP enough to do what we
need, including the decoding of the new DRM video system.
It SHOULD be upgradable-- USB IS a great idea!
It should also be user configurable, too. :)
Heck, as far as UI, there are already cheap, open touch-screen
options, and several open-source multimedia-player GUIs available
that can be modified to our needs.
Above all this- the reason for open systems- is that the radio
design, which will be in three primary parts- analogue hardware,
digital hardware and software- be completely survivable- That it, it
could survive any loss in sources, including the ultimate maker of
the radio itself.
Analogue hardware: This is the actual RF detection and mixing-- It
should be as sensitive and selective as possible.
Digital hardware: These include digital tuning, processor core,
programmable DSP core, and physical user interface, including
graphics hardware.
Digital software: This is the operating system, the user interface,
the receiver controls and frontend, and the DSP software and codecs.
The final design should be portable and use as little electrical
power as can be managed- An advantage to cheap off-the-shelf hardware
is that they use far less power than custom hardware. Above all else,
it should be usable by ANYONE. These radios might be marketed, and if
they do, it needs to work for the average radio listener, but still
of use to those who radio anoraks, like many of the DRM community at
present. Out of the box, it should be easy to use, easy to update
(REGARDLESS of the user's PC platform, if the user even HAS a PC!),
and feel useful, not just a pretty toy.
The core concept needs to be as future-proof as possible, even with
all designs and software out there for anyone to take as they wish--
The very notion of open-source hardware and software. Someone making
money at our expense? Great! That means it's out there, and will
remain out there! As long as we keep it open, we can make digital
radio cheap and open for all-- I'm not here to make money off of it,
but rather, I'd prefer to see that these efforts bring radios to
those who want them, and won't be rendered obsolete, just because the
radio manufacturers either go out of business or discontinue the
radios (and support!), leaving users withn expensive bricks-- Like my
Morphy Richards, the VERY REASON I came up with this concept in the
first place!
And it should be designable to have a Braille/blind user's interface,
for those who need it-- Like Hank, and in a few years....myself. Yes,
for me, this IS personal."
and one from Stephan Schaa:
" IMHO the dsPIC would be best suited for this job rather than the Arduino.
I would always plead for the use of a general puropose processor with an
architecture that is widely used by consumer hardware. In this case I would
mainly prefer an ARMv7 archtitecture (there may be a other very nice to use
processor in the starting hole, but for this later). The best thing would be
to use an existing design for the "mainboard", as I already said in the
interview that fibber made with me. This is for following reasons:
The most important reason is: keep it as simple as possible for all the
people that are involved in such a project! Keep this in mind all the time
when you start searching for a hardware or software solution.
Hardware platform
The people that can program software are mostly not the same people that
build hardware. So if you want to enable all people that are interested to
write software to do so, they will have to get some hardware that fits the
needs.
This is why I plead to use a exsiting hardware platform that is commonly
known and already widely sold.
This is why i think it's the best to use a commonly used ARM based
processor:
- which CPU is mostly used for embedded designs?
- which devices are well known for software writers to write software for
it?
- the device should be compatible with a commonly kown operating system
- which devices are used with (low) battery power?
- which devices (& development platforms) are available in small quantities
easy for people that would like to join the project
- which CPU may be available on the market for longer times ( same design or
compatible follow ups) to keep hardware and software easiely maintained
- are there different cpu variants available for different products with
different prices (and markets)? Low Cost ones with for example with low or
even no grafic features and lower processing power and better ones for
multimedia devices.
The ARM7 design is such a design with for example the Omap 3530 Processor
from TI would be a suitable CPU with the beagleboard (and all its relatives)
as developer platform; it's easy to buy, it's quite cheap for a developers
board and it's creative commons and it has all the features that we need
(plus some more). The processors used have enough processing power to
decode drm and the have also dsp functions (but i think code should be
written in that kind that allows to either use the dsp functions or don't
use them if you want to use another CPU without these functions). And the
beagleboard has a lot of possibilities to get connceted with it, usb, i2c,
seriell,...
Software platform
In order to get interest of as many software programmers as possible ist
neccessary to use a platform they know. DSP programming is very special so I
would tend to keep that parts as small as possible. My Idea to use android
came this way:
- Use a well known base platform that is widely spread, cheap to use and
commonly maintained -> Linux/Free BSD!
- which linux platforms keeps the software programming needs as low as
possible to create all the functions that are needed (baseband processing,
AAC decoding and User Interface)?
- which platform has good programming tools, cheap and easy to access for
software writers?
- which platform generates much interest for software writers to get
involved into such a project?
- which platform would generate the biggest impact to get as much DRM (and
shortwave) listeners as possible at the eadiest and cheapest way?
So I ended up at the android platform. It's open source linux based, it
comes with a developer platform, it's mostly used on Arm7 devices, it also
runs on X86 if neccasary, it's very attractive for software developers, it
has already the ability for multimedia, it comes with a good User interface.
And- last not least - there are already a lot of devices on the market which
run androis: think of the possiblities to get for example this device into a
DRM RX by plugging a usb based RX dongle into it and load the "App" from
android market:
http://www.pandawill.com/zenithink-zt180-epad-new-version-10-inch-mid-androi
d-21-wifi-720p-gravity-sensor-1ghz-cpu-rj45-adapter-silver_p37662.html ,
http://www.youtube.com/watch?v=8MMfeMCuUNw
> How about a modular approach?
This is a very good aproach. In order to get many different people to step
into the development it's very important to keep the modules as simple as
possible. Also this makes potential manufacturers more easy to change things
they might want to change.
I'm thinking that we should create a DRM decoder only.
If we could find some people that are able to do that and are willing to do
that then ist almost perfect. :-)
> Second question: do we want to attempt to build a DRM only, stand-alone
receiver or what?
The device should at least be able to play AM, FM and DRM. For FM it's maybe
more easy to do use "tricks" and build in a cheap, ready to use FM Chip
which has only to be (serial) controlled by the platform first.
> Another issue I see is overall sensitivity: the retail DRM radios have
tended to have less-than-great specifications,
> especially when it comes to use in our 'home' area of North America. Even
the Uniwave was found to be somewhat less
> than great here, yet is most likely satisfactory for East Asia and Europe.
Make it for our weaker signals and put an
> attenuator in it for the rest of the world. Anyway, just a thought.
This is one of the most important things. All the RF frontends of existing
standalone RX have been not very good so far. As far as I can see there are
three possible ways to get the signal from analog into the digital world:
- Baseband mixing and the use of a standard ADC Audio Chip (or codec)
- Use a RF Frontend Chip made by the industry (this has been made by
existing Standalone RX)
- Use a big ADC with FPGA to keep the analog part as small as possible (like
Perseus, Excalibur, ...) (this is the hardest and most costly way)
I would tend to start by the first way: Codecs are cheap, and if a USB based
chip would be used it would be also possible to use the hardware with other
devices (Notebook, Pad, ...) . And as long as you keep the ADC every RF
frontend could be used without changing to much at the software part."
I can't help but feel that we have some qualified technical specialists and first rate developers in our group. How can we coalesce around our key features and requirements and begin development?
