Harald Welte's blog
   

RSS

Harald's Web
gnumonks.org
hmw-consulting.de
sysmocom.de

Projects
OpenBSC
OsmocomBB
OsmocomTETRA
deDECTed.org
gpl-violations.org
gpl-devices.org
OpenMoko
gnufiish
OpenEZX
OpenBeacon
OpenPCD
librfid
openmrtd
opentom.org
netfilter/iptables

Categories

Archives

Other Bloggers
David Burgess
Zecke
Dieter Spaar
Michael Lauer
Stefan Schmidt
Rusty Russell
David Miller
Martin Pool
Jeremy Kerr
Tim Pritlove (German)
fukami (German)
fefe (German)
Bradley M. Kuhn
Lawrence Lessig
Kalyan Varma

Aggregators
kernelplanet.org
planet.netfilter.org
planet.openezx.org
planet.openmoko.org
planet.foss.in

Ohloh profile for laforge
identi.ca
twitter
flattr
Linked in
Xing

Creative Commons License
Articles on this blog/journal are licensed under a Creative Commons Attribution-NoDerivs 2.5 License.


blosxom


Contact/Impressum

       
Thu, 21 Jun 2012
First month of running the openmoko.org USB Product ID registry

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 List of assigned USB Product IDs in the openmoko.org wiki is turning into something like a directory of really cool projects with Open Hardware or at least Free Software device firmware.

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.

[ /electronics | permanent link ]

Mon, 21 May 2012
Openmoko USB Product ID and IEEE OUI (Ethernet MAC Address) range available to the community

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 USB Product ID and IEEE OUI (MAC Address) allocations to the community.

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.

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.

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 ;)

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.

I'd like to thank Openmoko Inc. and especially Sean Moss-Pultz for making this donation.

[ /electronics | permanent link ]

Mon, 09 Apr 2012
Name that UART: April 2012

It's sort of a cheap knock-off idea stolen from the Name that Ware on bunnies blog: 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 ;)

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.

So here is the device that I just took apart earlier today:

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:

  • You can see two signals going directly to a small unpopualted3-pin header
  • There are two other signals coming from somewhere under the main SoC
  • There are capacitors (C440, C441) directly connected to the U1 for the charge pump

[ /electronics | permanent link ]

Fri, 02 Mar 2012
OsmoSDR status update

It has been two months since I first was able to play with the OsmoSDR 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.

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.

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.

This was a really odd experience, as I've worked a lot with that very same SSC peripheral before, while writing firmware for the OpenPICC 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.

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.

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.

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!

So what had happened? The Atmel-provided reference code contained a

 #define BOARD_SSC_DMA_HW_SRC_REQ_ID      AT91C_HDMA_SRC_PER_3
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.

In case anyone else is interested, a patch can be found at my at91lib git repository.

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.

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.

One of the first captures can be found at this link, 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.

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.

[ /electronics | permanent link ]

Wed, 25 Jan 2012
First osmo-nvs-gps evaluation boards soldered

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.

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 ;)

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.

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 sysmocom webshop.

Schematics and Gerber files will be available at http://openbsc.osmocom.org/trac/wiki/osmo-nvs-gps soon.

[ /electronics | permanent link ]

Sat, 14 Jan 2012
First assembled prototypes of osmo-e1-xcvr

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 osmo-e1-xcvr.

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:

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.

[ /electronics | permanent link ]

Tue, 10 Jan 2012
OsmoSDR status update

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 http://sdr.osmocom.org/ website.

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:

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).

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.

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.

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.

So where do we stand? There are 5 prototypes of the first generation, they look like this:

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.

There will be a second generation board fixing this and other problems, and hopefully we'll see some progress in the weeks to come.

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.

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.

[ /electronics | permanent link ]

Fri, 23 Dec 2011
More "bare iron" development: OsmoSDR, osmo-e1-xcvr and SIM bank

I'm currently quite excited to be doing more bare iron programming as well as actual electrical engineering work again.

There's actually not just one project I'm working on, but a variety of them:

  • OsmoSDR - 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.
  • osmo-e1-xcvr - 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.
  • unnamed sim-bank project - 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 borrow 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?!?).

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.

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 shop.sysmocom.de, too.

[ /electronics | permanent link ]

Sat, 09 Apr 2011
Facebook "Open Compute Project" nothing but hot air

There has been a lot of fuzz about facebook's Open Compute Project, and it seems to originate mostly from journalists without much technical skill.

Did anyone actually bother to check what they released? You can find mechanical designs 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, ...)

It is sad to hear that they are 'openwashing' themselves (like BP is greenwashing itself). Specifically, the following portions are not "open":

  • Any type of electrical schematics (mainboards, power supply, ...)
  • Any type of detailed data sheets or programming manuals on the electronic components used
  • Gerber files of the PCBs

So what this really is all about is: Facebook advertising this is our new mechanical form factor, now we want all of you to adopt it, so we can buy cheaper hardware.

Go home, facebook. Come back if you have something _really_ open.

[ /electronics | permanent link ]

Sat, 29 Aug 2009
Wide-screen sucks for heavy terminal users

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.

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.

So despite having tried an ideapad S9e, a HP mininote 2133, I can only deem them unusable for any serious without an external display.

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.

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.

I've spent half the day in Seoul's Yeoksam Electronics Market. 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.

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.

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.

[ /electronics | permanent link ]

Wed, 29 Jul 2009
Embedded Projects Journal

As it seems, for about one year there has been a new Embedded Projects Journal (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.

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.

If you want to contribute, feel free to contact the journal's makers.

[ /electronics | permanent link ]

Sat, 17 Jan 2009
Why do all those netbook need to have fans?

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?

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.

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.

[ /electronics | permanent link ]

Sat, 30 Aug 2008
Photographs of disassembly and PCB of a e-ten glofiish X800

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.org.

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 ;)

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 the pictures of the disassembly process and PCB photographs here.

As you can see, the device employs the following major components / chipsets:

  • Samsung S3C2442B SoC with integrated SDRAM and NAND (same like Openmoko GTA02)
  • CSR4 based Bluetooth (same like Openmoko and many other devices)
  • microSD slot, must be connected to S3C2442 SD/MMC controller
  • 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)
  • TD028TTEC1 LCD module, exactly the same as the OpenMoko GTA01/GTA02
  • AKM 4641 audio codec, reportedly used in HP iPAQ and HTC Universal
  • Two cameras of unknown type, must be using the S3C2442 camera interface
  • 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.
  • A Xilinx CPLD

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) should 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.

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...

[ /electronics | permanent link ]

Thu, 27 Mar 2008
Schiphol airport uses active millimeter wave screening

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 L3 Communications ProVision(TM).

While doing some research about this subject on the net, I discovered cargo X-ray solutions such as those described in this article. 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...

[ /electronics | permanent link ]

Thu, 03 Jan 2008
Repairing VIA EPIA-ME6000 busted capacitors

Just before Christmas, my vdr 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.

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.

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.

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...

[ /electronics | permanent link ]

Mon, 04 Dec 2006
Petition against obnoxious WEEE implementation in Germany

There is now an official Petition to re-work the obnoxious WEEE implementation in Germany (see my detailed posting earlier in this blog. 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.

If you are German, and/or operate a business in Germany, please consider signing the above-mentioned petition!

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?

[ /electronics | permanent link ]

Mon, 02 Oct 2006
Obnoxious RoHS/WEEE rules and their German implementation

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.

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.

Now I actually am involved with producing small quantities of electronic equipment, 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.

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]).

The way how this system works is:

  • All manufacturers and importers have to register themselves with EAR
  • They also have to register the quantity (weight) of produced/imported goods every month
  • 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
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.

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".

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?

Wrong. The administrative fees of EAR.

  • 155 EUR one-time fee for registration is still quite acceptable.
  • 85 EUR per product that is put on the market is fine, too.
  • 100 EUR for each notice of change in production quantity is a bit steep, given the inevitable flux of that figure.
  • 455 EUR for the validation of the proof of having made the deposit
  • 215 EUR annually for the re-validation of the proof of having made the deposit

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 ?

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.

[ /electronics | permanent link ]

Mon, 25 Sep 2006
OpenPCD press release, online shop

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 OpenPCD shop is now online, and we're accepting orders from those people who don't want to fabricate the four-layer PCB themselves ;)

We also sent out the Press Release, in the hope that some press actually might be interested in free hardware project.

On OpenPCD.org we now also published the first binary firmware images (source code has always been in svn), including full USB DFU (device firmware upgrade) support.

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.

[ /electronics | permanent link ]

Thu, 06 Jul 2006
Visiting armzone.com in Shanghai

Today I had the pleasure of visiting armzone.com 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.

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?

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.

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.

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!

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...

[ /electronics | permanent link ]

Mon, 26 Jun 2006
Ridiculous fees for USB Vendor ID

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 USB Implementers Forum (IF).

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.

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.

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.

If the USB IF was really interested in stability and unique assignments, they would

  • reserve a couple of vendor ID's for experimental/ organization internal use
  • 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

[ /electronics | permanent link ]

Wed, 10 May 2006
Developing a 2.4GHz active RFID system

Together with Milosch from bitmanufaktur.de, 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.

So what's the point of all this? The goal is to have that system in operation at the HOPE Nr.6, 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.

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.

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.

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.

Kudos to bitmanufaktur. I wouldn't even dare to try to design a PCB for 2.4GHz RF...

[ /electronics | permanent link ]