Archive for October, 2007

CE Technical Documentation

Thursday, October 25th, 2007

The other week I went on a workshop to learn more about the new 89/336/EEC regulations that came into force in the UK on 20th July 2007. Here are some notes cribbed from my notes, they’re intended to be an overview: obviously for something this important you should get your own advice.

Out with the old ways…

For a long time it has been a requirement to certify that any product you manufacture for sale in the EU meets the “relevant standards”, so it can have a “CE” mark. Until this July in the UK you could either do that by:

  • paying for test at a “competent body”, a company with a ton of test gear that will empirically test your device against the emission and immunity standards, or
  • Writing up a Technical Construction File, or TCF, which described the product design in a deep way, and included tests and logic showing why you are compliant

Device torture at the House of Pain

The last design I completed, for a smart 4-channel Analogue telephony device that can hook to the Internet, I went down the empirical test route. At a total cost of several thousand pounds the production device was tested at a real competent body with calibrated receivers and emitters, blasted with wideband radio signals, zapped with +/- 8kV discharges. The resulting report gave a very clear okay except on a minor issue to do with the AC power supply we had used. We also had to do specialized testing for the analogue telephony end, which we again passed, although not until getting a component supplier to make a special that actually complies with the standard.

(Actually walking the device through this testing is a pretty sweaty business, since time is literally money at the test facility and wiggle room in the case of trouble is also in short supply. In one instance for example I was able to patch the sources in realtime when an issue came up during ESD testing that broke normal operation but wasn’t enough to trigger the watchdog, turning a fail into a pass. So I would never send a device unaccompanied for testing, or go to a test house without a laptop with full sources to expect the unexpected.)

In with the new ways…

However the demands in the new regulations have changed significantly. You must now generate “Technical Documentation” for any product you will be selling in the EU. This is basically the old TCF route to compliance, but it doesn’t itself necessarily remove or even perhaps reduce the need for absolute tests for a given device.

Less well known is that if you are still selling devices first sold before 20 July 2007 come 20 July 2009, you will need to have made a new style Technical Documentation for them, or stop selling them. A lot of tech products from 2007 will be old hat by 2009 solving the problem, but it is not true in all markets.

Typically the Technical Director of the company is the “responsible” as the French say who must sign off that the device meets the standards. What you are signing off on is that WHEN it is properly installed and maintained, and used for the purpose it is intended for:

  • the device creates an EM disturbance low enough that radio and telecoms equipment can operate as intended
  • it has a level of intrinsic immunity which is adequate to enable it to operate as intended

So what is done with this “Technical Documentation”?

Nothing if you’re lucky. The only people who can ask to look at it are the regulatory authorities, OFCOM in the UK. You don’t publish it or register a copy of it. But you have to keep it for ten years after the last sale of the device for the authorities to ask for. It literally only exists to keep the signatory out of jail if the authorities ask for it. Not kidding about the jail — if you don’t have a satisfactory Technical Documentation to show, the criminal penalties can include a GBP5,000 fine and/or 3 months in jail.

The key words about the Technical Documentation are that it should be “reasonable” and “duly diligent”, as in “All reasonable steps are exercised and all due diligence to avoid committing the offense”. That really sums up the job of writing it, you are trying to have an answer for anything that could be said was unreasonable or not duly diligent. While meeting budget constraints from the customer :-/

Spread of outcomes

The ways that problems might pan out were discussed informally. It was proposed that roughly a third of companies, the presenter reckoned, have their head totally in the sand about it, and could expect trouble. Another third had made some effort in the right direction and another third spent the money and were golden. Another factor in how much shit would rain down in the event of problems was the number of devices sold, if it was millions and they were crap, expect maximum warp to jail. If it is five and they don’t quite comply despite obvious efforts to prove it, maybe that won’t be so bad. But who knows, some overkill is called for.

How likely is my Technical Documentation to be demanded?

In Germany, we were told, the authorities have a system of testing 10,000 models of devices a year, spread over the various types of product. In the first year (IIRC) it resulted in 105 prosecutions :-/

Another tidbit is in the UK, OFCOM are allegedly looking at training up 85 new enforcement officers. The mobile phone companies, due to the ruinously expensive spectrum auctions of a few years ago, are apparently agitating for more enforcement of the cleanliness of their expensive 3G spectrum.

What goes in the Technical Documentation then?

Here is the briefest outline:

  • Description of apparatus – brand/model/manufacturer, intended function, limitations on operation… Technical description – block diagram, technical drawings, interconnections, variations, versions of design documents referenced
  • Procedures used to ensure conformity – Technical Rationale: what you’re testing against, why you did particular tests; Details of design: EMC features, component specifications, QA to control variation; Test data: Logical processes to decide if the tests are adequate, EMC tests and their results, external test reports on subassemblies/components

You can also get a Competent Body to “comment” on your Technical Documentation, as some fairly convincing assurance that it is adequate. This is really a seal on the “due diligence” aspect so you can really show you totally ticked every box to make sure it was compliant, but I guess only large companies can afford it.

Conclusion

If you manufacture or import stuff to sell in the EU, you are going to have to have Technical Documentation to keep yourself out of jail.

For a standalone device, that means you’re really going to have to not only look to dealing with EMC early in the design, with some kind of inhouse testing ability, but find the budget of a few thousand pounds to take it for testing at a Competent Body so you have something convincing and calibrated to put into that Technical Documentation.

Not only that, but even determining which are the applicable standards is a huge headache if you try to do it yourself, there are hundreds of them: a Competent body can also help select the basic issue of which tests you are targeting.

But it’s not all bad — if you make product variations around the same base, you can choose which variation to actually test as a baseline, and then for each variation see if it stands up to show they would not push the original base design over the edge. I have done this in the last couple of weeks, creating for a customer Technical Documentation for a sister device to one that went through actual testing at a Competent Body, and using the very large similarities to limit the amount of retesting needed.

There are definite advantages to requiring this level of design scrutiny and justification, but the change to requiring Technical Documentation and the trend to increased enforcement over the ten years you must keep the documentation has definitely pushed the minimum cost and effort of bringing something to market up several notches.

Posted in Hardware design | Comments Off

Drumbeat

Thursday, October 25th, 2007

The magic code project has gained a name and there are some new results to share.

The full sources for the experimental modem using the correlator codes is available at http://git.warmcat.com under GPL2+ license.

The big change is what I call “scrambling”.  The 126-bit magic correlator sequence is disordered and xor-ed in 258 random ways, which are selected to not correlate well with each other at any offset (less than 43/128 match).  This allows us to issue whole bytes in one code by selecting which disordered correlation code to transmit.  The other two codes are for start and end of packet markers. I first tried 22 scrambles to allow 4 bits per code and some extra codes, this worked fine but I was able to extend it to 258 without really damaging the “best” scramble-scramble false correlation score too much.

The gain here is that the self-ordering and threshold properties of the code now reaches up to entire bytes: you always get a clean, aligned byte or you don’t get anything: with high probability you don’t get a wrong byte.

I also changed the demodulator code to something that is currently quite expensive to run.  Instead of tracking a reference phase at the receiver, which is tough to do in the presence of extreme noise and phase wrapping, at each sample it tries to demodulate using that sample as “0 degrees” and a 50% phase slicer to get the bits.  It’s expensive because it has to do that against each of the 258 scrambles every sample — but on the plus side the correlator does not run at all for 124 symbols out of 126 (98.4% of the time) after there has been a successful decode, since it knows it is partway through a 126-symbol code. Still the number of demodulation attempts can definitely be reduced, maybe by subsequently just doing it on the last winning phase and a few either side.

I found that the noise performance of the demodulator is strongly dependent on the relationship between the sample rate and the carrier frequency.  It’s much less dependent on the number of carrier cycle periods per symbol, so long as you have 4 or 5 or above (2 works but is killed by hardly any noise).  Since there is plenty of filtering to the carrier going on I didn’t really expect that. Here is a graph of the noise performance when there are 96 samples per carrier (48kHz sample rate, 500Hz carrier, 100baud — these are intra-code symbols, it’s 6.25bits/sec effective):

The noise performance doesn’t look too bad, at least with these synthetic tests and unrealistic 48kHz sampling. It can recover all 7 bytes that are sent even at -28dB, when only 4% of the received power is the signal and the rest is white noise. And because of the code properties, these are definite bytes being captured with quite high probability, not the kind of uncertain decode that would normally be expected in such noise.

The “average quality %” shown in the graph is the percentage of demodulated bits in the matched code scramble that actually were “right”, averaged over all the bytes. If a byte is missing because its quality was below the threshold of 70/128, it counts as 0% quality. Up until -20dB, the demodulator is doing well and the recovering individual bits almost perfectly. Without the Correlator code, after -20dB you would be dealing with a rapid increase in bit errors from the demodulator and relying on ECC. By using the Correlator coding though, we are able to push performance another 8dB into the noise (we even recover half the symbols at -30dB, or 10dB further) and still maintain the alignment and high probability of correct decode advantages.

This shows the effect of keeping everything else the same, but bringing the sample rate down to 8kHz from 48kHz

You can see the BPSK demodulation starts to fail at -10dB instead of -20dB and the correlation code again buys you another 8 – 10dB into the noise after that.

Here is the spectrum after bandpass and lowpass filtering that is actually “transmitted”, the peak is the carrier at 500Hz in this case.

Another aspect of this setup is that although the demodulator is currently pretty expensive in CPU (and power), the modulator is much simpler. It just requires a 1KByte table for the scrambles and a precooked integer sine table if you are running a separate carrier than the RF one itself. Then it just needs enough logic to walk through the scramble table entry at the symbol rate (and the sine tables at the sample rate if you’re using it). That can fit in part of a tiny flash controller, using a 1-bit output of a shifter to switch the phase of the transmitter. It can be simplified even further by not using scrambles but just sending a bit per code sending the code forwards or backwards to signal a ’1′ or ’0′.

It seems that I can begin to understand where this system fits into the existing high noise codings already used by ham radio folks. The correlator code is a special case of using an ECC code, in this case where 8-ish bits are exploded into an 126-bit “space” filled with correct decodes, damaged but recoverable decodes and invalid decodes. The error correction performance of adding 8-10dB “coding gain” is probably a bit (not so much, from what I can work out) poorer than an optimal use of 126 bits to code for 8, but the advantages that attracted me to the code in the first place can offset that for some applications, the guaranteed self alignment right down from demodulation to byte boundaries, and a quite firm decode success threshold. In addition, it seems some of the more optimal decoding schemes for stuff like Viterbi can be very compute-intensive, whereas although at times we do a lot of it, the correlation action is simple and lends itself to being done in parallel. Turbo codes are patented. So it’s not a one size fits all technique, but it has its niche.

I guess the next stage is looking to BPSK modulate and recover an RF carrier directly, but that will need some thinking on because it will be a very frequency-specific design, unlike these baseband tests where you can just edit the important variables and recompile. For example if it can be done initially at the UK 40MHz ISM band it will be possible to consider logic looking at carrier zero-crossings for phase assessment easily enough, and to autocorrelate just the averaged recovered phase at 4 times the symbol rate.

Posted in Magic Correlator | Comments Off