LaForge's home page (Posts about electronics)https://laforge.gnumonks.org/blog/tags/electronics.atom2022-09-24T16:07:23ZHarald WelteNikolaPurism Librem 5 campaignhttps://laforge.gnumonks.org/blog/20170903-purism-librem5/2017-09-03T00:00:00+02:002017-09-03T00:00:00+02:00Harald Welte<p>There's a new project currently undergoing crowd funding that might be
of interest to the former Openmoko community: The <a class="reference external" href="https://puri.sm/shop/librem-5/">Purism Librem 5
campaign</a>.</p>
<p>Similar to <a class="reference external" href="http://openmoko.org/">Openmoko</a> a decade ago, they are
aiming to build a FOSS based smartphone built on GNU/Linux without any
proprietary drivers/blobs on the application processor, from
bootloader to userspace.</p>
<p>Furthermore (just like Openmoko) the baseband processor is fully
isolated, with no shared memory and with the Linux-running application
processor being in full control.</p>
<p>They go beyond what we wanted to do at Openmoko in offering hardware
kill switches for camera/phone/baseband/bluetooth. During Openmoko days
we assumed it is sufficient to simply control all those bits from the
trusted Linux domain, but of course once that might be compromised, a
physical kill switch provides a completely different level of security.</p>
<p>I wish them all the best, and hope they can leave a better track record
than Openmoko. Sure, we sold some thousands of phones, but the company
quickly died, and the state of software was far from end-user-ready. I
think the primary obstacles/complexities are verification of the
hardware design as well as the software stack all the way up to the UI.</p>
<p>The budget of ~ 1.5 million seems extremely tight from my point of view,
but then I have no information about how much Puri.sm is able to invest
from other sources outside of the campaign.</p>
<p>If you're a FOSS developer with a strong interest in a Free/Open
privacy-first smartphone, please note that they have several job openings, from
<a class="reference external" href="https://puri.sm/job/kernel-driver-developer/">Kernel Developer</a> to
<a class="reference external" href="https://puri.sm/job/pureos-phone-developer-os/">OS Developer</a>
to <a class="reference external" href="https://puri.sm/job/pureos-phone-developer-ui/">UI Developer</a>.
I'd love to see some talents at work in that area.</p>
<p>It's a bit of a pity that almost all of the actual technical details are
unspecified at this point (except RAM/flash/main-cpu). No details on
the cellular modem/chipset used, no details on the camera, neither on
the bluetooth chipset, wifi chipset, etc. This might be an indication
of the early stage of their plannings. I would have expected that one
has ironed out those questions before looking for funding - but then,
it's their campaign and they can run it as they see it fit!</p>
<p>I for my part have just put in a pledge for one phone. Let's see what
will come of it. In case you feel motivated by this post to join in:
Please keep in mind that any crowdfunding campaign bears significant
financial risks. So please make sure you made up your mind and don't
blame my blog post for luring you into spending money :)</p>The sad state of voice support in cellular modemshttps://laforge.gnumonks.org/blog/20170902-cellular_modems-voice/2017-09-02T00:00:00+02:002017-09-02T00:00:00+02:00Harald Welte<p>Cellular modems have existed for decades and come in many shapes and kinds. They contain the cellular
baseband processor, RF frontend, protocol stack software and anything else required to communicate with a
cellular network. Basically <em>a phone without display or input</em>.</p>
<p>During the last decade or so, the vast majority of cellular modems come as LGA modules, i.e. a small PCB with
all components on the top side (and a shielding can), which has contact pads on the bottom so you can solder
it onto your mainboard. You can obtain them from vendors such as Sierra Wireless, u-blox, Quectel, ZTE,
Huawei, Telit, Gemalto, and many others.</p>
<p>In most cases, the vendors now also solder those modules to small adapter boards to offer the same product
in mPCIe form-factor. Other modems are directly manufactured in mPCIe or NGFF aka m.2 form-factor.</p>
<p>As long as those modems were still 2G / 2.5G / 2.75G, the main interconnection with the host (often some
embedded system) was a serial UART. The Audio input/output for voice calls was made available as analog
signals, ready to connect a microphone and spekaer, as that's what the cellular chipsets were designed for in
the smartphones. In the Openmoko phones we also interfaced the audio of the cellular modem in analog, exactly
for that reason.</p>
<p>From 3G onwards, the primary interface towards the host is now USB, with the modem running as a USB device.
If your laptop contains a cellular modem, you will see it show up in the <code class="docutils literal">lsusb</code> output.</p>
<p>From that point onwards, it would have made a lot of sense to simply expose the audio also via USB. Simply
offer a multi-function USB device that has both whatever virutal serial ports for AT commands and network
device for IP, and add a USB Audio device to it. It would simply show up as a "USB sound card" to the host,
with all standard drivers working as expected. Sadly, nobody seems to have implemented this, at least not in
a supported production version of their product</p>
<p>Instead, what some modem vendors have implemented as an ugly hack is the transport of 8kHz 16bit PCM samples
over one of the UARTs. See for example the Quectel UC-20 or the Simcom SIM7100 which implement such a method.</p>
<p>All the others ignore any acess to the audio stream from software to a large part. One wonders why that is.
From a software and systems architecture perspective it would be super easy. Instead, what most vendors do,
is to expose a digital PCM interface. This is suboptimal in many ways:</p>
<ul class="simple">
<li><p>there is no mPCIe standard on which pins PCM should be exposed</p></li>
<li><p>no standard product (like laptop, router, ...) with mPCIe slot will have anything connected to those PCM
pins</p></li>
</ul>
<p>Furthermore, each manufacturer / modem seems to support a different subset of dialect of the PCM interface in
terms of</p>
<ul class="simple">
<li><p>voltage (almost all of them are 1.8V, while mPCIe signals normally are 3.3V logic level)</p></li>
<li><p>master/slave (almost all of them insist on being a clock master)</p></li>
<li><p>sample format (alaw/ulaw/linear)</p></li>
<li><p>clock/bit rate (mostly 2.048 MHz, but can be as low as 128kHz)</p></li>
<li><p>frame sync (mostly short frame sync that ends before the first bit of the sample)</p></li>
<li><p>endianness (mostly MSB first)</p></li>
<li><p>clock phase (mostly change signals at rising edge; sample at falling edge)</p></li>
</ul>
<p>It's a real nightmare, when it could be so simple. If they implemented USB-Audio, you could plug a cellular
modem into any board with a mPCIe slot and it would simply work. As they don't, you need a specially designed
mainboard that implements exactly the specific dialect/version of PCM of the given modem.</p>
<p>By the way, the most "amazing" vendor seems to be u-blox. Their Modems support PCM audio, but only the
solder-type version. They simply didn't route those signals to the mPCIe slot, making audio impossible to use
when using a connectorized modem. How inconvenient.</p>
<div class="section" id="summary">
<h2>Summary</h2>
<p>If you want to access the audio signals of a cellular modem from software, then you either</p>
<ul class="simple">
<li><p>have standard hardware and pick one very specific modem model and hope this is available sufficiently long during your application, or</p></li>
<li><p>build your own hardware implementing a PCM slave interface and then pick + choose your cellular modem</p></li>
</ul>
<p>On the Osmocom <a class="reference external" href="https://osmocom.org/projects/mpcie-breakout/wiki">mpcie-breakout board</a> and the <a class="reference external" href="https://www.sysmocom.de/products/sysmoqmod/index.html">sysmocom
QMOD board</a> we have exposed the PCM related pins on
2.54mm headers to allow for some separate board to pick up that PCM and offer it to the host system. However,
such separate board hasn't been developed so far.</p>
</div>Upcoming v3 of Open Hardware miniPCIe WWAN modem USB breakout boardhttps://laforge.gnumonks.org/blog/20170324-mpcie_breakout-v3/2017-03-24T00:00:00+01:002017-03-24T00:00:00+01:00Harald Welte<p>Back in October 2016 I designed <a class="reference external" href="https://laforge.gnumonks.org/blog/20170324-mpcie_breakout-v3/FIXME">a small open hardware breakout board
for WWAN modems in mPCIe form-factor</a>. I was thinking some
other people might be interested in this, and indeed, the first
manufacturing batch is already sold out by now.</p>
<p>Instead of ordering more of the old (v2) design, I decided to do some
improvements in the next version:</p>
<ul class="simple">
<li><p>add mounting holes so the PCB can be mounted via M3 screws</p></li>
<li><p>add U.FL and SMA sockets, so the modems are connected via a short U.FL
to U.FL cable, and external antennas or other RF components can be
attached via SMA. This provides strain relief for the external
antenna or cabling and avoids tearing off any of the current loose
U.FL to SMA pigtails</p></li>
<li><p>flip the SIM slot to the top side of the PCB, so it can be accessed
even after mounting the board to some base plate or enclosure via the
mounting holes</p></li>
<li><p>more meaningful labeling of the silk screen, including the purpose of
the jumpers and the input voltage.</p></li>
</ul>
<p>A software rendering of the resulting v3 PCB design files that I just
sent for production looks like this:</p>
<img alt="/images/mpcie-breakout-v3-pcb-rendering.png" src="https://laforge.gnumonks.org/images/mpcie-breakout-v3-pcb-rendering.png">
<p>Like before, the design of the board (including schematics and PCB
layout design files) is available as open hardware under CC-BY-SA
license terms. For more information see
<a class="reference external" href="http://osmocom.org/projects/mpcie-breakout/wiki">http://osmocom.org/projects/mpcie-breakout/wiki</a></p>
<p>It will take some expected three weeks until I'll see the first
assembled boards.</p>
<p>I'm also planning to do a M.2 / NGFF version of it, but haven't found
the time to get around doing it so far.</p>GTA04 project halts GTA04A5 due to OMAP3 PoP soldering issueshttps://laforge.gnumonks.org/blog/20170306-gta04-omap3_pop_soldering/2017-03-06T00:00:00+01:002017-03-06T00:00:00+01:00Harald Welte<p>For those of you who don't know what the <a class="reference external" href="http://projects.goldelico.com/p/gta04-main/">tinkerphones/OpenPhoenux GTA04</a> is: It is a
'professional hobbyist' hardware project (with at least public
schematics, even if not open hardware in the sense that editable
schematics and PCB design files are published) creating updated
mainboards that can be used to upgrade Openmoko phones. They fit into
the same enclosure and can use the same display/speaker/microphone.</p>
<p>What the GTA04 guys have been doing for many years is close to a miracle
anyway: Trying to build a modern-day smartphone in low quantities,
using off-the-shelf components available in those low quantities, and
without a large company with its associated financial backing.</p>
<p>Smartphones are complex because they are highly integrated devices. A
seemingly unlimited amount of components is squeezed in the tiniest
form-factors. This leads to complex circuit boards with many layers
that take a lot of effort to design, and are expensive to build in low
quantities. The fine-pitch components mandated by the integration
density is another issue.</p>
<p>Building the original GTA01 (Neo1937) and GTA02 (FreeRunner) devices at
Openmoko, Inc. must seem like a piece of cake compared to what the GTA04
guys are up to. We had a team of engineers that were familiar at last
with feature phone design before, and we had the backing of a consumer
electronics company with all its manufacturing resources and expertise.</p>
<p>Nevertheless, a small group of people around Dr. Nikolaus Schaller has
been pushing the limits of what you can do in a small <em>for fun</em>
project, and the have my utmost respect. Well done!</p>
<p>Unfortunately, there are bad news. Manufacturing of their latest
generation of phones (GTA04A5) <a class="reference external" href="http://lists.goldelico.com/pipermail/gta04-owner/2017-February/007259.html">has been stopped due to massive soldering
problems with the TI OMAP3 package-on-package (PoP)</a>.
Those PoPs are basically "RAM chip soldered onto the CPU, and the stack
of both soldered to the PCB". This is used to save PCB footprint and to
avoid having to route tons of extra (sensitive, matched) traces between
the SDRAM and the CPU.</p>
<p>According to the mailing list posts, it seems to be incredibly difficult
to solder the PoP stack due to the way TI has designed the packaging of
the DM3730. If you want more gory details, see
<a class="reference external" href="http://lists.goldelico.com/pipermail/gta04-owner/2017-February/007262.html">this post</a>
and <a class="reference external" href="http://lists.goldelico.com/pipermail/gta04-owner/2017-February/007271.html">yet another post</a>.</p>
<p>It is very sad to see that what appears to be bad design choices at TI
are going to bring the GTA04 project to a halt. The financial hit by
having only 33% yield is already more than the small community can take,
let alone unused parts that are now in stock or even thinking about
further experiments related to the manufacturability of those chips.</p>
<p>If there's anyone with hands-on manufacturing experience on the DM3730
(or similar) TI PoP reading this: Please reach out to the GTA04 guys and
see if there's anything that can be done to help them.</p>
<dl class="field-list simple">
<dt>UPDATE (March 8, 2017)</dt>
<dd><p>In an earlier post I was asserting that the GTA04 is open hardware
(which I actually believed up to that point) until some readers have
pointed out to me that it isn't. It's sad it isn't, but still it has
my sympathies.</p>
</dd>
</dl>Autodesk: How to lose loyal EAGLE customershttps://laforge.gnumonks.org/blog/20170123-eagle-autodesk/2017-01-23T00:00:00+01:002017-01-23T00:00:00+01:00Harald Welte<p>A few days ago, Autodesk has <a class="reference external" href="http://www.autodesk.com/products/eagle/blog/the-new-eagle-subscription-has-landed/">announecd</a>
that the popular EAGLE electronics design automation (EDA) software is
moving to a subscription based model.</p>
<p>When previously you paid once for a license and could use that
version/license as long as you wanted, there now is a monthly
subscription fee. Once you stop paying, you loose the right to use the
software. Welcome to the brave new world.</p>
<p>I have remotely observed this subscription model as a general trend in
the proprietary software universe. So far it hasn't affected me at all,
as the only two proprietary applications I use on a regular basis
during the last decade are IDA and EAGLE.</p>
<p>I already have ethical issues with using non-free software, but those
two cases have been the exceptions, in order to get to the productivity
required by the job. While I can somehow convince my consciousness in
those two cases that it's OK - using software under a subscription model is
completely out of the question, period. Not only would I end up paying
for the rest of my professional career in order to be able to open and
maintain old design files, but I would also have to accept software that
"calls home" and has "remote kill" features. This is clearly not
something I would ever want to use on any of my computers. Also, I
don't want software to be associated with any account, and it's not the
bloody business of the software maker to know when and where I use my
software.</p>
<p>For me - and I hope for many, many other EAGLE users - this move is
utterly unacceptable and certainly marks the end of any business between
the EAGLE makers and myself and/or my companies. I will happily use
my current "old-style" EAGLE 7.x licenses for the near future, and theS
see what kind of improvements I would need to contribute to KiCAD or
other FOSS EDA software in order to eventually migrate to those.</p>
<p>As expected, this doesn't only upset me, but many other customers, some
of whom have been loyal to using EAGLE for many years if not decades,
back to the DOS version. This is reflected by some media reports (like
<a class="reference external" href="https://hackaday.com/2017/01/19/autodesk-moves-eagle-to-subscription-only-pricing/">this one at hackaday</a>
or user posts <a class="reference external" href="https://www.element14.com/community/thread/36623/l/new-eagle-licensing-goodbye-eagle?displayFullThread=true">at element14.com</a> or <a class="reference external" href="http://www.eaglecentral.ca/index.php/t/52901/90be6616cc619dc651e072c006dec854/">eaglecentral.ca</a>
who are similarly critical of this move.</p>
<p>Rest in Peace, EAGLE. I hope Autodesk gets what they deserve: A new
influx of migrations away from EAGLE into the direction of Open Source
EDA software like KiCAD.</p>
<p>In fact, the more I think about it, I'm actually very much inclined to
work on good FOSS migration tools / converters - not only for my own
use, but to help more people move away from EAGLE. It's not that I
don't have enough projects at my hand already, but at least I'm
motivated to do something about this betrayal by Autodesk. Let's see
what (if any) will come out of this.</p>
<p>So let's see it that way: What Autodesk is doing is raising the level
off pain of using EAGLE so high that more people will use and contribute
FOSS EDA software. And that is actually a good thing!</p>Open Hardware miniPCIe WWAN modem USB breakout board releasedhttps://laforge.gnumonks.org/blog/20161125-mpcie_breakout/2016-11-25T00:00:00+01:002016-11-25T00:00:00+01:00Harald Welte<p>There are plenty of cellular modems on the market in the mPCIe form
factor.</p>
<p>Playing with such modems is reasonably easy, you can simply insert them
in a mPCIe slot of a laptop or an embedded device (soekris, pc-engines
or the like).</p>
<p>However, many of those modems actually export interesting signals like
digital PCM audio or UART ports on some of the mPCIe pins, both in
standard and in non-standard ways. Those signals are inaccessible in
those embedded devices or in your laptop.</p>
<p>So I built a small break-out board which performs the basic function of
exposing the mPCIe USB signals on a USB mini-B socket, providing power
supply to the mPCIe modem, offering a SIM card slot at the bottom, and
exposing all additional pins of the mPCIe header on a standard 2.54mm
pitch header for further experimentation.</p>
<img alt="/images/mpcie-breakout-front.jpg" src="https://laforge.gnumonks.org/images/mpcie-breakout-front.jpg">
<p>The design of the board (including schematics and PCB layout design
files) is available as open hardware under CC-BY-SA license terms. For
more information see <a class="reference external" href="http://osmocom.org/projects/mpcie-breakout/wiki">http://osmocom.org/projects/mpcie-breakout/wiki</a></p>
<p>If you don't want to build your own board, fully assembled and tested
boards are available from
<a class="reference external" href="http://shop.sysmocom.de/products/minipcie-wwan-modem-usb-break-out-board">http://shop.sysmocom.de/products/minipcie-wwan-modem-usb-break-out-board</a></p>Open Hardware Multi-Voltage USB UART board releasedhttps://laforge.gnumonks.org/blog/20161125-multivoltage_uart/2016-11-25T00:00:00+01:002016-11-25T00:00:00+01:00Harald Welte<p>During the past 16 years I have been playing a lot with a variety of
embedded devices.</p>
<p>One of the most important tasks for debugging or analyzing embedded
devices is usually to get access to the serial console on the UART of
the device. That UART is often exposed at whatever logic level the main
CPU/SOC/uC is running on. For 5V and 3.3V that is easy, but for ever
more and more unusual voltages I always had to build a custom cable or a
custom level shifter.</p>
<p>In 2016, I finally couldn't resist any longer and built a multi-voltage
USB UART adapter.</p>
<p>This board exposes two UARTs at a user-selectable voltage of 1.8, 2.3,
2.5, 2.8, 3.0 or 3.3V. It can also use whatever other logic voltage
between 1.8 and 3.3V, if it can source a reference of that voltage from
the target embedded board.</p>
<img alt="/images/mv-uart-front.jpg" src="https://laforge.gnumonks.org/images/mv-uart-front.jpg">
<p>Rather than just building one for myself, I released the design as open
hardware under CC-BY-SA license terms. Full schematics + PCB layout
design files are available. For more information see
<a class="reference external" href="http://osmocom.org/projects/mv-uart/wiki">http://osmocom.org/projects/mv-uart/wiki</a></p>
<p>In case you don't want to build it from scratch, ready-made machine
assembled boards are also made available from
<a class="reference external" href="http://shop.sysmocom.de/products/multi-voltage-usb-dual-uart">http://shop.sysmocom.de/products/multi-voltage-usb-dual-uart</a></p>Volunteer for Openmoko.org USB Product ID maintenancehttps://laforge.gnumonks.org/blog/20151206-volunterr-wanted-usb_iids/2015-12-06T00:00:00+01:002015-12-06T00:00:00+01:00Harald Welte<p>Back when Openmoko took the fall, we donated the Openmoko, Inc. USB
Vendor ID to the community and started the registry of free Product ID
allocations at <a class="reference external" href="http://wiki.openmoko.org/wiki/USB_Product_IDs">http://wiki.openmoko.org/wiki/USB_Product_IDs</a></p>
<p>Given my many other involvements and constant overload, I've been doing a
poor job at maintaining it, i.e. handling incoming requests.</p>
<p>So I'm looking for somebody who can reliably take care of it, including</p>
<blockquote>
<ul class="simple">
<li><p>reviewing if the project fulfills the criteria (hardware or software
already released under FOSS license)</p></li>
<li><p>entering new allocations to the wiki</p></li>
<li><p>informing applicants of their allocation</p></li>
</ul>
</blockquote>
<p>The amount of work is actually not that much (like one mail per week), but
it needs somebody to reliably respond to the requests in a shorter time
frame than I can currently do.</p>
<p>Please let me know if you'd like to volunteer.</p>First month of running the openmoko.org USB Product ID registryhttps://laforge.gnumonks.org/blog/20120621-free_software_usb_pid_first_month/2012-06-21T03:00:00+02:002012-06-21T03:00:00+02:00Harald Welte<p>
One month ago, I had announced the availability of USB Product IDs under
the Openmoko USB Vendor ID. By now, there have been 37 registrations,
and the <a href="http://wiki.openmoko.org/wiki/USB_Product_IDs#USB_Vendor_and_Product_IDs">List
of assigned USB Product IDs in the openmoko.org wiki</a> is turning into
something like a directory of really cool projects with Open Hardware or
at least Free Software device firmware.
</p>
<p>
So actually, I enjoy a lot seeing so much activity in this field, and
being able to contribute a tiny bit by enabling people to get a unique
USB Product ID that they can use.
</p>Openmoko USB Product ID and IEEE OUI (Ethernet MAC Address) range available to the communityhttps://laforge.gnumonks.org/blog/20120521-open_registry_for_usb_and_mac_addrs/2012-05-21T03:00:00+02:002012-05-21T03:00:00+02:00Harald Welte<p>
As it has been quite some time since Openmoko, Inc. (the company) has
released any hardware, I have obtained the permission to "donate" the
Openmoko-assigned <a href="http://wiki.openmoko.org/wiki/USB_Product_IDs#Conditions">USB
Product ID</a> and <a href="http://wiki.openmoko.org/wiki/OUI#Conditions">IEEE OUI (MAC
Address)</a> allocations to the community.
</p>
<p>
As the actual allocations cannot be transferred unless the registrant
(Openmoko. Inc.) is sold, the official registration will remain with
Openmoko Inc. while the various Free / Open Source Software and hardware
communities can make use of the range.
</p>
<p>
Registering a USB Vendor ID is expensive (USD 2000), and even if it
wasn't for the money, many companies (let even aside community projects)
will never require the 65535 product IDs allocated within that one USB
Vendor ID.
</p>
<p>
As for Ethernet/Wifi/Bluetooth MAC addresses, they are allocated from
the IEE OUI number ranges, which are also quite expensive (USD 1600) -
but at least you get 16.7 million (24bit) and not just 16bit like USB ;)
</p>
<p>
So if you are running a small homebrew or community built project that
implements a USB device or Ethernet ports, and either the software or
the hardware of it is available under a free software / open source
license, you can follow the instructions given at the pages in the
Openmoko wiki that I linked above and request an allocation.
</p>
<p>
I'd like to thank Openmoko Inc. and especially Sean Moss-Pultz for
making this donation.
</p>Name that UART: April 2012https://laforge.gnumonks.org/blog/20120409-name_that_uart/2012-04-09T03:00:00+02:002012-04-09T03:00:00+02:00Harald Welte<p>
It's sort of a cheap knock-off idea stolen from the <i>Name that
Ware</i> on <a href="http://www.bunniestudios.com/blog/">bunnies
blog</a>: I'm going to post one picture every month about a UART that
I found on embedded hardware. Unfortunately I don't have much to offer
in terms of a reward for whoever finds the true solution ;)
</p>
<p>
In any case, every month there are devices that I'm looking into either
out of my own interest, or because the work at gpl-violations.org
requires it. In most of them, you can find a UART to get to the u-boot
/ Linux serial console.
</p>
<p>
So here is the device that I just took apart earlier today:
</p>
<center>
<img src="http://laforge.gnumonks.org/photos/201204-uarts_everywhere.jpg" width="50%">
</center>
<p>
The location of the UART pads was obvious, after looking at the PCB for
a very short time. The entire unpopulated U1 footprint appeared
suspiciously like a UART level shifter for true RS232 voltage levels:
</p><ul> <li>You can see two signals going directly to a small
unpopualted3-pin
header</li>
<li>There are two other signals coming from somewhere under the main SoC</li>
<li>There are capacitors (C440, C441) directly connected to the U1 for the charge pump</li>
</ul>OsmoSDR status updatehttps://laforge.gnumonks.org/blog/20120302-osmosdr-update/2012-03-02T03:00:00+01:002012-03-02T03:00:00+01:00Harald Welte<p>
It has been two months since I first was able to play with the <a href="http://sdr.osmocom.org/">OsmoSDR</a> hardware prototypes. Back at
that time, there was no FPGA code yet, and some hardware bugs still had
to be resolved. Nonetheless, the e4k tuner driver could already be
implemented and tuning was confirmed by looking at the analog i/q
spectrum.
</p>
<p>
Meanwhile, the hardware has been re-worked by SR-Systems and FPGA VHDL
code written by maintech.de. Ever since that, they dropped the ball
again with me as I had been careless enough to volunteer for writing
the firmware.
</p>
<p>
And that's what I did or at least tried to do for quite some time during
the last two weeks. The main problem was that I didn't have much time.
The second problem was that I never was able to get the SSC (synchronous
serial controller) receive DMA working.
</p>
<p>
This was a really odd experience, as I've worked a lot with that very
same SSC peripheral before, while writing firmware for the <a href="http://www.openpcd.org/OpenPICC_RFID_Emulator_and_Sniffer_Project">OpenPICC</a>
some 6 years ago. However, this was in an at91sam7s, where the SSC is
interfaced with the PDC (Peripheral DMA Controller). In the at91sam3u
of OsmoSDR, it interfaces with a more modern DMAC/HDMA controller,
capable of scatter-gather DMA and other fancy stuff.
</p>
<p>
Atmel has provided reference code that uses the SSC DMA in transmit mode
(for a USB audio device playing back music via the Wolfson codec on the
SAM3U-EK board). After thoroughly studying the DMAC/HDMA documentation I
set out to write code for DMA-based SSC receiver. And it never worked.
</p>
<p>
I actually wrote two independent implementations, one from scratch and
the other based on Atmel reference code. Neither of them worked. It
seemed to be a problem with the hardware hand-shaking between SSC and
DMAC. The SSC was successfully receiving data, and that data could be
read out from the CPU using a polling or IRQ based driver. But if
you're running at something like 32 Mbps and don't have a FIFO, you
desperately want to use DMA. When the DMA handshaking was turned off,
the DMA code worked, but of course it read the same received word
several thousand times before the next data arrived on the SSC.
</p>
<p>
In the end, I was actually convinced it must be a silicon bug. Until I
thought well, maybe they just connected the flow controller to a
different ID in Rx and Tx direction. Since there are only 16 such
identifiers, it was relatively easy to brute-force all of them and see
if it worked. And voila - using the identifier 4, it worked!
</p>
<p>
So what had happened? The Atmel-provided reference code contained a
</p><pre>
#define BOARD_SSC_DMA_HW_SRC_REQ_ID AT91C_HDMA_SRC_PER_3
</pre>
and that was wrong. 3 is valid for SSC TX but not for SSC RX.
Unfortunately I never found any of those magic numbers in the SAM3U
manual either. They are not documented in the chapter of the SSC, and
they are not documented in the chapter about HDMA/DMAC either. And they
are not identical with the Peripheral Identifiers that are used all over
the chip for the built-in peripherals.
<p>
In case anyone else is interested, a patch can be found at <a href="https://gitea.osmocom.org/laforge/at91lib/commit/e3a39f0d8b3174ea4d266069f13c40485ea7e16c">my
at91lib git repository</a>.
</p><p>
I filed a ticket with Atmel support, and they pointed out in fact there
was a table with those identifiers somewhere in the early introductory
chapters where you can see a brief summary of the features of each
integrated peripheral. Unfortunately they use slightly different naming
in that chapter and in the DMAC, so a full-text search also didn't find
them. Neither is that table visible in the PDF index.
</p>
<p>
So about four man-days later it was finally working. Another day was
spent on integrating it with the USB DMA for sending high-speed
isochronous transfers over the bus into the PC. And ever since I'm
happily receiving something like 500,000 or 1,000,000 samples / second
from an alsa device, using snd-usb-audio. Luckily, unlike MacOS or
Windows, the Linux audio drivers don't make arbitrary restrictions in
the sample rate. According to the USB Audio spec, the sample rate can
be any 24bit number. So audio devices with 16.7 Ms/s are very much
within the spec. I hope some of the other OS driver writers would take
that to their heart.
</p>
<p>
One of the first captures can be found at <a href="http://people.osmocom.org/laforge/osmo-sdr/osmosdr_fm_capture_loud.wav.bz2">this
link</a>, containing a bzip2ed wave file in S16LE format Stereo (I/Q).
It contains a FM audio signal transmitted using a small pocket-sized FM
transmitter.
</p>
<p>
There is no I/Q DC offset calibration yet, but once that is done we're
probably able to finally put the design into production.
</p>First osmo-nvs-gps evaluation boards solderedhttps://laforge.gnumonks.org/blog/20120125-osmo_nvs_gps/2012-01-25T03:00:00+01:002012-01-25T03:00:00+01:00Harald Welte<p>
At the osmocom project, we recently discovered the most interesting NVS
NV08C-CSM module. It not only is a superb GPS receiver, but it includes
GALILEO and GLONASS receivers, too. However, it's only available as an
industry module, or as an expensive (700 EUR or so) evaluation kit.
</p>
<p>
Given the cheap PCB prototyping service at seeedstudio, I thought I'd
spend an afternoon creating the schematics and PCB layout for an
evaluation board. It exports the two 3.3V UARTs on OsmocomBB-style
2.5mm jacks, so they can be used with the T191 cables. I have the
feeling this 2.5mm jack is becoming a new standard for low-voltage RS232
links ;)
</p>
<center>
<img src="http://openbsc.osmocom.org/trac/raw-attachment/wiki/osmo-nvs-gps/osmo-nvs-gps.jpg" width="33%">
</center>
<p>
Furthermore, it exports the SPI, I/O and I2C on a 20pin 2.54mm pitch
header, connects to an external antenna via a MCX socket and has an
optional footprint for a CR2032 battery on the bottom side.
</p>
<p>
So far, the board seems to be working fine. If there is interest in the
bare PCB itself (without components!), please send me an e-mail.
Depending on the amount of interest we might add it to the <a href="http://shop.sysmocom.org/">sysmocom webshop</a>.
</p>
<p>
Schematics and Gerber files will be available at <a href="http://openbsc.osmocom.org/trac/wiki/osmo-nvs-gps">http://openbsc.osmocom.org/trac/wiki/osmo-nvs-gps</a>
soon.
</p>First assembled prototypes of osmo-e1-xcvrhttps://laforge.gnumonks.org/blog/20120114-osmo_e1_xcvr/2012-01-14T03:00:00+01:002012-01-14T03:00:00+01:00Harald Welte<p>
I mentioned it briefly before: I've designed a small E1/T1/J1 transceiver
board, which is going to be used for experimentally interfacing such a TDM
line with microcontroller and/or FPGA. The name of this board is <a href="http://openbsc.osmocom.org/trac/wiki/osmo-e1-xcvr">osmo-e1-xcvr</a>.
</p>
<p>
The first prototype PCBs have arrived yesterday, and despite lots of other
more important work I couldn't resist but to actually solder some of the units.
The result can be seen here:
</p>
<center>
<img src="http://openbsc.osmocom.org/trac/raw-attachment/wiki/osmo-e1-xcvr/osmo-e1-xcvr.jpg" width="50%">
</center>
<p>
I don't have time to do anything beyond very basic testing right now, but so
far the boards seem to be doing fine. Now we need a driver for the transceiver
chip, and connect its control interface over SPI to some microcontroller
(likely sam7s/sam3s/sam3u in my case). The actual serial bitstream will end up
at the SSC peripheral of the controller.
</p>OsmoSDR status updatehttps://laforge.gnumonks.org/blog/20120110-osmosdr/2012-01-10T03:00:00+01:002012-01-10T03:00:00+01:00Harald Welte<p>
It's already two weeks since my last post mentioning OsmoSDR only very
briefly. By now, OsmoSDR is fully public and you can read all about it
on the <a href="http://sdr.osmocom.org/">http://sdr.osmocom.org/</a>
website.
</p>
<p>
Specifically, the website includes Schematics, and one of my colorful
block diagrams. I am a text guy and really hate to work with graphics,
but the block diagram of the Calypso has helped a lot in the context of
making people understand OsmocomBB, so I tried again for OsmoSDR:
</p>
<p>
</p><center>
<img src="http://sdr.osmocom.org/trac/raw-attachment/wiki/Hardware/osmo_sdr_block.png" width="66%">
</center>
<p>
So as you can see, it is a very simple, straight-forward design with a
chip tuner, direct I/Q down-conversion, ADC for differential I and Q
signals as well as a small FPGA for basic filtering and serial format
conversion, followed by a Atmel SAM3U microcontroller (Cortex-M3, high
speed USB).
</p>
<p>
And yes, it's receive only. However, it has a stacking connector for
later addition of a transmit daughter-board which may eventually follow
later in 2012.
</p>
<p>
So what is this OsmoSDR going to be used for? Well, for receiving any
kind of signals between 64 MHz and 1700 MHz (possibly up to 1800 MHz,
untested). We don't build it for a specific application, but we simply
thought that for many applications a member of the USRP family is
expensive overkill, and the FCDP has this arbitrary restriction at 96
kHz sampling frequency.
</p>
<p>
Please note that while I may be the only OsmoSDR developer that blogs
about this project, it is very much a team effort and I'm only a minor
part of that team. Apart from selecting the SAM3U, writing firmware and
drivers for it as well as some discussions early on in the project, I
didn't have any involvement in the Hardware design. Those credits go to
Christian Daniel and Stefan Reimann.
</p>
<p>
So where do we stand? There are 5 prototypes of the first generation,
they look like this:
</p><center>
<img src="http://sdr.osmocom.org/trac/raw-attachment/wiki/WikiStart/osmosdr.jpg" width="50%">
</center>
<p>
There are some smaller hardware issues that were easy to work around,
but one bigger problem related to the fact that the Si570 programmable
oscillator output levels didn't match quite with what the FPGA clock
input requires.
</p>
<p>
There will be a second generation board fixing this and other problems,
and hopefully we'll see some progress in the weeks to come.
</p>
<p>
Firmware-wise, the code is currently scattered over a couple of
different repositories, but I'm going to consolidate that soon. If
you've worked with OpenPCD or SIMtrace, you will find some similarities:
We split the flash of the controller into two partitions: One for the
DFU bootloader, and one for the application code. You can then use the
USB DFU (Device Firmware Upgrade) standard to quickly update the actual
firmware of the device, without having to resort to jumpers or
un-plugging and re-plugging of the hardware.
</p>
<p>
This also meant that I had to re-implement the old sam7dfu code for the
SAM3U, which has considerable differences in the USB peripheral, cpu
core, board startup code, etc. So it's really a reimplementation than a
port. The good news is that I tried to make it as general as possible
and integrate it with at91lib, Atmels reference code. So it should be
easier to use it with other Atmel SoCs like the sam3s which I want to
use e.g. in SIMtrace v2.
</p>More "bare iron" development: OsmoSDR, osmo-e1-xcvr and SIM bankhttps://laforge.gnumonks.org/blog/20111223-embedded_development/2011-12-23T03:00:00+01:002011-12-23T03:00:00+01:00Harald Welte<p>
I'm currently quite excited to be doing more <i>bare iron</i>
programming as well as actual electrical engineering work again.
</p>
<p>
There's actually not just one project I'm working on, but a variety of
them:
</p><ul>
<li><b>OsmoSDR</b> - an upcoming small form-factor, inexpensive USB SDR. Not
big and expensive like USRP or real "professional" solutions, but also
not as weak as the ultra-narrow-band funcube dongle. I wasn't involved
in the hardware design, but have volunteered to take care of the
firmware development for the Atmel SAM3U micro-controller inside.</li>
<li><b><a href="http://openbsc.osmocom.org/trac/wiki/osmo-e1-xcvr">osmo-e1-xcvr</a></b>
- a relatively simple circuit board containing the magnetics, LIU, clock
generation and transceiver for E1/T1/J1 lines.
The idea here is to have a solution for the analog part, as well as
HDB3/B8ZS/AMI encoding, which can then be attached to any FPGA, CPLD or
micro-controller development board. It exposes SPI for controlling the
transceiver, and a synchronous serial bit-stream for Rx and Tx.
</li><li><b>unnamed sim-bank project</b> - here the goal is to find a cheap
solution to attach a large number of SIM cards to either a PC or
directly to Ethernet. This can be very useful for testing, where you
host your sim cards in a centralized location and can <i>borrow</i> them
to remote users/devices over TCP/IP. There are commercial devices
available for this, but they are quite expensive (like 1700 USD for 32
card device) and intended to be used with some proprietary windows
software (who wants that?!?). </li>
</ul>
<p>
In the latter two projects I'm also doing the component selection,
schematics design and PCB layout. One project with KiCAD, the other
in EAGLE, as I really want to get first-hand experience of the usability
of Free vs. proprietary EDA tools. I'd love to also evaluate Altium
Designer, but they are still windows-only, and that would just make life
way too difficult for me.
</p>
<p>
The projects will be duly announced soon, and they are all intended to
be Open Hardware designs with Free Software. We'll probably also make
all of them available at <a href="http://shop.sysmocom.de">shop.sysmocom.de</a>, too.
</p>Facebook "Open Compute Project" nothing but hot airhttps://laforge.gnumonks.org/blog/20110409-facebook_opencompute_hot_air/2011-04-09T03:00:00+02:002011-04-09T03:00:00+02:00Harald Welte<p>
There has been a lot of fuzz about facebook's <a href="http://opencompute.org/">Open Compute Project</a>, and it seems to
originate mostly from journalists without much technical skill.
</p>
<p>
Did anyone actually bother to check what they released? You can find
<a href="http://opencompute.org/servers/">mechanical designs</a> and simple
specification data sheets. More or less every vendor is publishing that kind
of information, or at least there are common form factors that are specified
(like ATX, eATX, mini-ITX, ...)
</p>
<p>
It is sad to hear that they are 'openwashing' themselves (like BP is
greenwashing itself). Specifically, the following portions are not "open":
</p><ul>
<li>Any type of electrical schematics (mainboards, power supply, ...)</li>
<li>Any type of detailed data sheets or programming manuals on the electronic components used</li>
<li>Gerber files of the PCBs</li>
</ul>
<p>
So what this really is all about is: Facebook advertising <i>this is our new
mechanical form factor, now we want all of you to adopt it, so we can buy
cheaper hardware</i>.
</p>
<p>
Go home, facebook. Come back if you have something _really_ open.
</p>Wide-screen sucks for heavy terminal usershttps://laforge.gnumonks.org/blog/20090829-widescreen_sucks/2009-08-29T03:00:00+02:002009-08-29T03:00:00+02:00Harald Welte<p>
I've always been complaining loudly about wide-screen displays. 4:3 is much
better for those of us who mainly work with xterms of 80 characters width (due
to e.g. kernel coding style and e-mail conventions). The additional width
is typically not enough for having three terminal windows next to each other,
but the lacking height means way less visible lines of code.
</p>
<p>
This is why I'm still using my Panasonic CF-R5 (10.2" 1024x768 sub-notebook) from
2006. Despite it almost falling apart on all sides after three years of most
intensive daily use, despite it feeling slower than any Atom based netbook that
I've used.
</p>
<p>
So despite having tried an ideapad S9e, a HP mininote 2133, I can only deem
them unusable for any serious without an external display.
</p>
<p>
Right now I'm desperately looking for a device that can be the successor for
the CF-R5. I don't need much computing power, a Atom N270 would be the minimum
but would work. I am happy with narrow keyboards as I'm using one for 3 years
every day. I don't need tons of memory as I'm not using any bloated graphical
desktop (just ion+uxterm). All I care about is Intel integrated graphics, a
small device, ideally 10", with at least 768 pixels height.
</p>
<p>
It seems there are now 1366x768 based 10" netbooks, but all you can find is
nVidia based Samsung devices, which are obviously completely unsuitable for,
considering nVidia treats the FOSS community like crap.
</p>
<p>
I've spent half the day in <a href="http://en.wikipedia.org/wiki/Yongsan_Electronics_Market">Seoul's Yeoksam
Electronics Market</a>. The only thing that would remotely resemble my
requirements is the ASUS eeePC 1101HA. But it's 11.6" wide screen, which makes
the device considerably wider/larger than the CF-R5. Plus, the maximum memory
configuration is 2G.
</p>
<p>
The other options is to buy a CF-R8. Still 4:3 ratio, almost the same size as
the CF-R5. If only Panasonic was selling them outside the US. Yes, I know you
can mail order them. But I'd love to have a look and try it before spending at
least 1500 EUR on it.
</p>
<p>
So the Notebook industry still fails to impress me. Noisy (with fan) devices
with ever wider screens. Apparently ignoring the fact that there are people
who can imagine more interesting things to do with their computer than to play
movies.
</p>Embedded Projects Journalhttps://laforge.gnumonks.org/blog/20090729-embedded_projects_journal/2009-07-29T03:00:00+02:002009-07-29T03:00:00+02:00Harald Welte<p>
As it seems, for about one year there has been a new <a href="http://www.embedded-projects.net/index.php?page_id=238">Embedded Projects
Journal</a> (in German). This magazine focuses entirely on FOSS embedded
projects and open hardware. The idea is to have a magazine written by the
community for the community. Plus, the magazine and all its articles are
freely redistributable.
</p>
<p>
It's a pity that I've only noticed about this now. Let's hope more people
learn about it, now that I'm mentioning it here.
</p>
<p>
If you want to contribute, feel free to contact the journal's makers.
</p>Why do all those netbook need to have fans?https://laforge.gnumonks.org/blog/20090117-netbooks_and_their_fans/2009-01-17T03:00:00+01:002009-01-17T03:00:00+01:00Harald Welte<p>
This is a question that I've been asking myself ever since the first eeePC was
released. Sure, there are other problems like bad keyboards and mechanical
design (with the exception of the HP mininotes) and too small / low-res displays.
But the question that bothers me most is: Why do those
supposedly-so-power-saving new processors still need a fan in those systems?
</p>
<p>
I am the happy owner of a Panasonic Let's Note CF-R5. It was bought in
September 2006, where it was already end-of-life. It does not have nor need a
fan, the Intel U1300 (1.06GHz) CPU and the Intel IGP chipset are doing quite
fine without it. So why are the supposedly less power-consuming later systems
like Intel Atom built with fans? It's really annoying to me. I don't want this
kind of noisy design. It sucks. It is a clear sign of bad engineering.
</p>
<p>
So far, the only replacement for the CF-R5 that I would consider is a CF-R7 or
CF-R8. A netbook faster than the CF-R5 without fan could make me reconsider.
</p>Photographs of disassembly and PCB of a e-ten glofiish X800https://laforge.gnumonks.org/blog/20080830-eten_glofiish_x800-pcb-photographs/2008-08-30T03:00:00+02:002008-08-30T03:00:00+02:00Harald Welte<p>
Heh. You could say I'm now among other things a professional hardware reverse
engineer. This mostly started as a kid, where I always had to take everything
apart. In more recent years, I've mostly been doing hardware reverse engineering
as part of the gpl-violations.org effort, or projects like openezx.osmocom.org.
</p>
<p>
Now, I've actually been asked by a company to buy a device on their expense to
disassemble and photograph it, to find out about the components it uses, etc.
And no, before you start to wonder, I don't work for Openmoko anymore. So they
are not that company ;)
</p>
<p>
The device in question is the E-TEN glofiish X800, a full-vga 3.5G Windows
Mobile PDA-Phone with AGPS, Wifi and bluetooth. You can find
<a href="http://laforge.gnumonks.org/photoalbum/devices/eten_glofiish_x800/pics/index.html">the pictures of the disassembly process and PCB photographs here</a>.
</p>
<p>
As you can see, the device employs the following major components / chipsets:
</p><ul>
<li>Samsung S3C2442B SoC with integrated SDRAM and NAND (same like Openmoko GTA02)</li>
<li>CSR4 based Bluetooth (same like Openmoko and many other devices)</li>
<li>microSD slot, must be connected to S3C2442 SD/MMC controller</li>
<li>WiFi Module using a Marvell 8686 chipset (you actually can't see that, I had to peel open the shielding of the module and the angle didn't allow any good photographs)</li>
<li>TD028TTEC1 LCD module, exactly the same as the OpenMoko GTA01/GTA02</li>
<li>AKM 4641 audio codec, reportedly used in HP iPAQ and HTC Universal</li>
<li>Two cameras of unknown type, must be using the S3C2442 camera interface</li>
<li>Ericsson based quad-band GSM and tri-band 3.5G chipset centered around
the DB3150, which is used in many Sony-Ericcson 3G/3.5G phones. Sony-Ericsson
has excellent public documentation on their AT-commandset for their phones.
Since they are likely to use the same firmware base, the AT commandset should thus be known.</li>
<li>A Xilinx CPLD</li>
</ul>
<p>
So now what does all this mean? Setting aside the CPLD and the unknown camera
modules, this device (and its keyboard-enabled brother the M800) <i>should</i>
be a very attractive target for porting Linux to it. Known SoC, wifi with
driver already in mainline, GSM/3.5G modem with documented AT commands, etc.
</p>
<p>
Big question is the power management. It looks like they're using a lot of
discrete regulators rather than an integrated PMU. Also, the CPLD is likely
to cause a lot of trouble since neither the external connection nor the
internal logic is known...
</p>Schiphol airport uses active millimeter wave screeninghttps://laforge.gnumonks.org/blog/20080327-active_mm_wave_screening_schiphol/2008-03-27T03:00:00+01:002008-03-27T03:00:00+01:00Harald Welte<p>
I was quite surprised that Amsterdam airport is beginning to introduce
active millimeter wave screening instead of the good old metal detectors.
The specific device seen in operation at one of the queues between the
international and the Schengen area of the airport was <a href="http://www.dsxray.com/products/mmwave.htm">L3 Communications ProVision(TM)</a>.
</p>
<p>
While doing some research about this subject on the net, I discovered
cargo X-ray solutions such as those described <a href="http://www.airport-int.com/categories/mobile-xray-systems/cargo-xray-inspection.asp">in
this article</a>. You can mount a mobile unit onto a track and then go as deep
as 200mm of steel to x-ray through the metal plating of a cargo container. This
is really scary stuff...
</p>Repairing VIA EPIA-ME6000 busted capacitorshttps://laforge.gnumonks.org/blog/20080103-epia-vdr-repair-capacitors/2008-01-03T03:00:00+01:002008-01-03T03:00:00+01:00Harald Welte<p>
Just before Christmas, my <a href="http://www.cadsoftusa.com/vdr/">vdr</a>
powered diskless Linux-based digital video recorder went bust. A bit of
testing revealed that the VIA EPIA-ME6000 main board itself must be dead.
</p>
<p>
I immediately ordered a replacement mini-ITX board without further
investigating the broken one, expecting that the replacement might actually
arrive before the Christmas holidays. Unfortunately this didn't happen. While
replacing the board, I discovered that six of the 1000uF electrolytic capacitors
went bust.
</p>
<p>
So today I finally found a bit of time (it's great to be able to find time to
do things again) to try and replace the broken capacitors. Despite the new
ones being slightly larger, the board now works again like a charm. And that
at a total cost of 1.62 EUR.
</p>
<p>
So now I have two working mini-ITX boards. Guess I have to either find some
use for it, or sell the new one again...
</p>Petition against obnoxious WEEE implementation in Germanyhttps://laforge.gnumonks.org/blog/20061204-weee_petition_germany/2006-12-04T03:00:00+01:002006-12-04T03:00:00+01:00Harald Welte<p>
There is now an official <a href="http://itc.napier.ac.uk/e-Petition/bundestag/view_petition.asp?PetitionID=332">Petition</a>
to re-work the obnoxious WEEE implementation in Germany (see my <a href="http://gnumonks.org/~laforge/weblog/2006/10/02#20061002-rohs-weee">detailed
posting earlier in this blog</a>. This is good, and definitely a step forward
in getting regulations in place which are supportive of small and medium-sized companies,
rather them getting them out of business. I've spoken to lawyers about the current
regulations, and they e.g. have severe doubt that they are even constitutional.
</p>
<p>
If you are German, and/or operate a business in Germany, please consider
signing the above-mentioned petition!
</p>
<p>
btw: I'm planning to start a petition against hosting petitions of the German
Bundestag at a University in the UK, anybody interested in joining it?
</p>Obnoxious RoHS/WEEE rules and their German implementationhttps://laforge.gnumonks.org/blog/20061002-rohs-weee/2006-10-02T03:00:00+02:002006-10-02T03:00:00+02:00Harald Welte<p>
You might have heard about RoHS (Reduction of Hazardous Substances) before. I
always thought it is a well-meant and important contribution of the European Union
to reduce the amount of hazardous substances in electronic waste. As a
supporter of many environmental groups, and an occasional voter for the Green
party, I definitely support such a goal.
</p>
<p>
If I was to manufacture electronic equipment, then certainly I would consider
it as my moral duty to pay for the cost of processing ('recycling', how they
call it, if that was ever possible)the resulting waste. No debate on that at all.
</p>
<p>
Now I actually am involved with <a href="http://openpcd.org/">producing small
quantities of electronic equipment</a>, and suddenly those issues come up again.
The product obviously only uses RoHS compliant components, no question on that.
We do want to reduce the environmental impact, after all.
</p>
<p>
Now enter EU and German bureaucracy, combined with lobbying of large industrial
electronics manufacturers, and you end up with the German implementation called
"ElektroG" (Gesetz ueber das Inverkehrbringen, die Ruecknahme und die
umweltfreundliche Entsorgung von Elektro- und Elektronikgeraeten [Law about
distribution, withdrawal and eco-friendly disposal of electrical and electronic
devices]). That law basically regulates and delegates the administration of
the RoHS/WEEE guidelines to an authority called EAR (Stiftung
Elektro-Altgeraete Register [Foundation for Registry of Electrical Devices]).
</p>
<p>
The way how this system works is:
</p><ul>
<li>All manufacturers and importers have to register themselves with EAR</li>
<li>They also have to register the quantity (weight) of produced/imported goods every month</li>
<li>They furthermore have to produce proof of having made a deposit on the amount of money
required to "recycle" the resulting electronic waste, even in the case of bankruptcy of
the producer/importer</li>
</ul>
This all sounds very reasonable and well-thought. Given the facts stated until
here, I would still be an avid supporter of such a system.
<p>
Now enter the disaster: The minimum quantity that this system can deal with is
the metric ton. This is very suitable for large manufacturers, but what about
a small company that produces 100 units of 180grams of weight every year? It will take
more than 55 years to fill up that metric ton. Now, if they actually allowed you to pay for one ton every 55 years, then that would be great. Obviously, they don't. Rather they employ an
undisclosed lottery algorithm, which elects one registered producer/importer who
has to take care of recycling one specific container that was filled last at the electronics
waste collection station. Yes, every time one container is filled, they elect another lucky
lottery winner. And in order to make sure that every possible "winner" could actually afford
the disposal of that container, EAR has the "proof of bankruptcy-safe deposit".
</p>
<p>
You might think: Well, quite a fancy system, but assuming that algorithm was tuned right,
there still is no problem, even for small producers, since the probability of them being chosen
by the lottery is very low. And in fact it is. An EAR person has publicly stated in an
interview that only producers having produced more than 3.5 metric tons of
electronics are eligible to win that lottery. Great, since in our example that
would be in 194 years. Son nothing to worry about, right?
</p>
<p>
Wrong. The administrative fees of EAR.
</p><ul>
<li>155 EUR one-time fee for registration is still quite acceptable.</li>
<li>85 EUR per product that is put on the market is fine, too.</li>
<li>100 EUR for each notice of change in production quantity is a bit steep,
given the inevitable flux of that figure.</li>
<li>455 EUR for the validation of the proof of having made the deposit</li>
<li>215 EUR <b>annually</b> for the re-validation of the proof of having made the deposit</li>
</ul>
<p>
Now what kind of bull**it is this? This means that during those 55 years we
would fill one metric ton, we'd have to pay 12066 EUR only in administrative
fees for validation and re-validation of the bankruptcy-save deposit? All that
for the disposal of one ton of electronic waste, which costs [now] between 200
and 400EUR ?
</p>
<p>
I would be very surprised if such fees would not violate anti competition rules
of the EU somewhere at some point. This is the creation of a serious market
entrance barrier for small manufacturers of electronic equipment and nothing else.
</p>OpenPCD press release, online shophttps://laforge.gnumonks.org/blog/20060925-openpcd-pressrelease/2006-09-25T03:00:00+02:002006-09-25T03:00:00+02:00Harald Welte<p>
Ok, after a painful day full of shippin rates, insurance, taxation issues, etc.
Milosch finally worked out how to ship our product to about any country of the
wokld. This means that the <a href="http://shop.openpcd.org/">OpenPCD shop</a>
is now online, and we're accepting orders from those people who don't want to
fabricate the four-layer PCB themselves ;)
</p>
<p>
We also sent out the <a href="http://www.openpcd.org/news.0.html#20060925-pressrelease">Press
Release</a>, in the hope that some press actually might be interested in free
hardware project.
</p>
<p>
On <a href="http://www.openpcd.org/">OpenPCD.org</a> we now also published the
first binary firmware images (source code has always been in <a href="http://svn.openpcd.org/">svn</a>), including full USB DFU (device
firmware upgrade) support.
</p>
<p>
If I manage to resolve some of the problems I still have with the SAM7 SSC
controller, then the PICC simulator should also get working some time soon.
</p>Visiting armzone.com in Shanghaihttps://laforge.gnumonks.org/blog/20060706-shanghai-armzone/2006-07-06T03:00:00+02:002006-07-06T03:00:00+02:00Harald Welte<p>
Today I had the pleasure of visiting <a href="http://www.armzone.com/">armzone.com</a> in Shanghai. Now if that was like visiting any other hardware or electronics store, I wouldn't be blogging about it. It might actually be that visiting any shop like this in China is a similar experience. But I'll write it anyway, you don't have to read it.
</p>
<p>
So we were there to buy some S3C2410 based development boards (full-featured,
basically PDA development boards, including 65MB SDRAM, 64MB NAND Flash,
Ethernet, USB host and device, a CPLD, IDE, 2xSerial, JTAG, SD-Card, ..). The
first thing to notice was the price. Including a touch screen LCD panel they
were something like USD 180 each. Actually less than any PDA based on them
would cost in the western world. Aren't devel boards usually at least one
order of magnitude more expensive than the actual systems you're going to
design with them?
</p>
<p>
Then we were looking for some JTAG adaptor compatible with that devel board.
The boards ship with a wiggler, which is supported by OpenOCD and also some
s3c2410 version of JFlash, but which is slow as hell. Sort of the least
interesting option. They had a number of USB and parallel port models
available, some of them clones of well-known modules such as MultiICE, some
others being developed by themselves.
</p>
<p>
The main problem was that they all seem to require some RDI server to run
on a windows box. Hey, If I'm doing Linux target development on a Linux host
system, they ask me to run a windows box just for that daemon? They must be
kidding me. So my Chinese contacts engaged in some almost two hour debate on
whether he couldn't release the source code to their own RDI server so I can
port/re-implement that code on Linux, and why it might be a benefit to them to
get that Linux version back to ship with further products. The debate also
seems to have included all kinds of other options. Going as far as to the shop
wanting to sell us a Raven compatible device, to which we almost agreed, only
to learn that he needs a week to produce some more apart from the engineering
sample.
</p>
<p>
One other thing we'd need for the parallel port versions is a PCMCIA parport
card. Yes, such things actually exist, and you can buy them even on some
Chinese eBay like site whose name I forgot. Rather than buying that, armzone
offered us to wait two weeks, until then they will have built (!) their own
parport adaptor for only a part of the price. Yes, they would have gone all
the way down to molding a case for the parport connector sticking out of
PCMCIA, etc. And that for us buying a max of 5 of those cards. Hey, we're
talking about electronics / PCB / case design here, not about whether I want ketchup with my french fries!
</p>
<p>
This seriously made me wonder whether when you buy a car in China they also
ask you if they should be personally just for you build a different car radio
from scratch. These guys are crazy...
</p>Ridiculous fees for USB Vendor IDhttps://laforge.gnumonks.org/blog/20060626-usb_vendor_id/2006-06-26T03:00:00+02:002006-06-26T03:00:00+02:00Harald Welte<p>
Sometimes you happen to find yourself starting a DIY electronics project, much
like a Free Software project. And if that hardware is actually to be plugged
into one of the standard interfaces such as the various PCI variants, or USB,
then you'll need to give it a USB Vendor and Device ID. Vendor ID's are 16bit,
and allocated by the <a href="http://www.usb.org/">USB Implementers Forum (IF)</a>.
</p>
<p>
Unfortunately, applying for a Vendor ID costs you USD 2,000. Yes, two-thousand
bucks US for creating an entry in a table. This might be peanuts for large
hardware companies, but it's an awfully large amount of money for any of the many
USB hardware projects that people tend to experiment with. Especially since
micro-controllers with embedded USB device controller are quite commonplace these days.
</p>
<p>
In the software / Internet world, there also are unique ID's that need to be
applied for. I'm talking about protocol numbers, port numbers and the like. I've
already applied for a number of them at bodies such as IANA. Obviously they are
for free. This way you can ensure not to use values that get later assigned to
other organizations/projects, and everything is clean.
</p>
<p>
Ridiculous fees such as the USB IF fee for a Vendor ID are just leading to the
situation when independent developers will chose random ID's, which will sooner
or later clash with other vendors and his devices.
</p>
<p>
If the USB IF was really interested in stability and unique assignments, they
would
</p><ul>
<li>reserve a couple of vendor ID's for experimental/ organization internal use</li>
<li>create a hand full of vendor ID's which are not assigned to any vendor, but
where hobbyists and Free Hardware developers can have individual device ID's assigned
to themselves, e.g. like the IANA protocol/port number process works
</li></ul>Developing a 2.4GHz active RFID systemhttps://laforge.gnumonks.org/blog/20060510-rfid-hope/2006-05-10T03:00:00+02:002006-05-10T03:00:00+02:00Harald Welte<p>
Together with Milosch from <a href="http://www.bitmanufaktur.de/">bitmanufaktur.de</a>, I've spent a couple
of days and nights working on building our own 2.4GHz active RFID system. The parameters are:
Battery powered, small transponders based on the Nordic Semiconductor nRF24L01
and a ultra-low-power PIC micro-controller. Base-stations have the same nRF
chip, plus an Ethernet-enabled micro-controller. Operational range is ~10
meters, we even made it through two walls in our preliminary tests.
</p>
<p>
So what's the point of all this? The goal is to have that system in operation
at the <a href="http://www.hopenumbersix.net/">HOPE Nr.6</a>, and to give a
practical demonstration on how feasible it is to track people, make protocols
on who has spent how much time in which lecture hall, etc.
</p>
<p>
I'm not involved with HOPE at all, but was only involved in writing firmware
and higher-level code for the two embedded systems involved, as well as some
testing.
</p>
<p>
I'm looking forward to learn how the system will perform with several
hundreds/thousands of transponders at its first real-world test at HOPE. With
some luck, we can have the same system at 23C3 in December this year in Berlin.
</p>
<p>
Until then I'm certainly going to try to implement my idea for peer-to-peer
time slot synchronization of the transponders. I had that idea as a solution to avoid
collisions between transponders while working on the project. Unfortunately, the
current transponder hardware doesn't have a low-power timing source that is precise enough for
such a protocol. Adding a 32.768kHz low-power quartz should do the trick - but
will inevitably also make the transponder more costly.
</p>
<p>
Kudos to bitmanufaktur. I wouldn't even dare to try to design a PCB for 2.4GHz RF...
</p>