Posts

james pawson emc speaking at iot leeds

“EMC for IoT” Presentation at the IoT Leeds Meetup

I had the pleasure of speaking at the local IoT Leeds meetup, held at the newly (and finally) renovated “Platform” venue just outside of the train station. The views over Leeds city centre from our 10th floor suite where the event was being held were impressive.

view over Leeds from floor 10 of the Platform building

Paul Wealls of Mokanix had the first slot and gave an interesting talk on their development toolkit for mobile applications. I’m not a software engineer (my code makes grown men weep) but the usefulness of this cross network toolkit was evident and seemed to generate a lot of interest among the attendees. Well worth checking out if that’s your bag.

The synopsis of my presentation, titled “EMC for IoT” was a very high level overview of the European EMC and Radio Regulations for IoT hardware, CE marking, and the importance of spectrum protection through compliance. Because I didn’t know the makeup of the audience beforehand it was tricky to know exactly what sort of content to put in. I opted for more graphics than words which gives more flexibility in the subjects covered.

emc for iot slide front page

In the end, in the audience of around twenty people, there were two (and a half) hardware engineers, mostly software engineers but everyone had a technical background. As such I skewed the presentation towards the general but still went into detail where necessary. I really enjoy speaking on EMC matters and it’s great fun to share knowledge with like-minded interested professionals.

The questions received after the presentation were all very intelligent and well thought out. They ranged from instances of counterfeit components causing EMC problems, understanding risk, the costs involved and the use of mobile devices on aircraft. Despite what can be seen as a dry subject the feedback from the presentation was very good.

james pawson emc speaking at iot leeds

photo credit Will Newton

It was also great to see my ex colleague Chris who I hadn’t seen for a long time and catch up with him. We both headed to the Leeds Brewery Tap for a pint of Midnight Bell with Will (organiser) and Neil and for a chat that ranged from the local job market to AI before hopping on the train home. All in all, a good evening!

I’m looking to take the talk out on the road for other meetups or organisations so if you know anyone running an technical event where this would fit in then I’d be interested to hear about it.

 

 

IoT EMC Radiated Emissions Investigations

A customer requested some support with one of their products, an IoT bridge device that takes various sensors and provides telemetry back to a central server using a GSM module. Some of the radio pre-compliance spurious emissions testing had suggested there might be some issues at certain frequencies.

After a couple of hours of radiated emissions measurements in the anechoic chamber and some bench work with some near field probes, I’d developed a pretty good idea of what was going on in terms of where the emissions were coming from and what their radiating mechanisms were.

Interestingly, there was a common theme to all of these emissions…

These features are common to a wide range of similar devices so some notes and a simple drawing (oddly I find sketching like this a good way to relax!) are presented in the hope it will give you some ideas about where your radiated emissions might be coming from.

The sketch shows a keypad board, a CPU board and a battery pack. Some other information is missing to permit a simpler drawing. All of these boards below sandwich together nicely into a plastic case which was the starting point for the investigation.

The problem frequencies identified were a 300MHz narrowband spike and a 250MHz broadband hump. Usually when I see broadband I think “power supply noise” and narrowband I think “digital noise”.

IoT module - emc radiated emissions analysis

Let’s take a wander around the device.

Capacitive plate near field probing around (A) showed higher than background levels of 300MHz noise around the front panel button board. Since this was a “dumb” board, the noise was probably coming from the main CPU board. The noise emanating from the cable (B) was not appreciably higher but when approaching the CPU/memory the noise increased, the clock line between the memory device and CPU being the highest.

Two possibilities were that there was crosstalk on the PCB at (C) or perhaps inside the CPU itself but without getting into more complex analysis the exact cause is not known. Apart from the power lines, there was no extra HF filtering on the data lines, just a series resistor on the I/O lines of the CPU. The addition of a small capacitor (e.g. 47pF, either 0402 or an array) on each line to circuit ground forms an RC filter to roll off any unwanted HF emissions like this. I generally advocate making provision for such devices on the PCB but not fitting them unless required – better to provision for and not need than to require a PCB re-spin later in the development cycle.

Moving the near field probe around the bottom of the case where the battery lives (D) showed the broad 250MHz hump present on the battery. Unplugging the battery pack made the emissions drop by 10dBuV/m and measuring with a high bandwidth passive probe showed broadband noise present on the outputs of the battery charger (E) from the switching converter. Some low-ohm ferrite beads in series with the battery terminals will help keep this noise on board and prevent common mode emissions from the battery and cables (F).

Lastly, the antenna was unplugged and some other broadband noise was found on the cable (G) at 360MHz, this time from the main 5V DC/DC converter on the main PCB.

 

Conclusion

So what is the common theme? All the radiation problems stem from cables connected to the main PCB. As soon as you add a cable to a system you are creating a conductor with a poorly controlled return path or “antenna” as they are sometimes known in the EMC department!

Treat any cable or connector leaving your PCB as an EMC hazard. You have less control over the HF return paths in the cable environment than you do on the PCB. Apply appropriate HF filtering to the lines on the cable and remember that even a shielded cable can cause problems.

Sometimes, like the antenna cable, there’s not a lot you can do about it other than practice good design partitioning to keep noisy sources away from the cable and to apply a ferrite core around the cable if it becomes a problem during testing.

 

I hope you found this useful and that it has given you some pointers for looking at your own designs with a new perspective.

 

IoT Security Seminar Report

I attended a really interesting technical conference on IoT security yesterday at the Digital Exchange right here in Bradford (organised by Future Electronics).

The main message I took away was that IoT security is achievable but requires a lot of thought up front at the design stage including selection of the primary hardware to enable secure identification of the IoT node. Obviously the level security should be aligned with the value of the asset being secured and that is down to the security risk assessment performed (or not!) by the manufacturer.

First we enjoyed a superb talk by Ken Munro from Pen Test Partners on ethical hacking of IoT devices and how compromised security of one device can lead to a whole heap of problems. Examples included a large DDos botnet made from compromised CCTV DVRs, plain text passwords stored in a Wi-Fi kettle and hacked building management systems being used to mine Bitcoins.

Microchip Technology Inc. gave a talk on their ECC508/608 and demonstrated how it can be used (with Amazon Web Services) to uniquely identify and verify an IoT node in an easily embeddable package. This was a well delivered presentation that covered

Following on from that, there were some good presentations from NXP Semiconductors on their A1006 devices and smartcard based signing ecosystem, ST Microelectronics on their ST32 microcontroller security and ST Safe modules, and lastly Arm on their mbed OS and mbed cloud security features.

Overall it was a well organised event; the Digital Exchange building on Peckover Street has been well converted into a conference and working space. It was nice to meet some new faces as well as catch up with old ones. My only regret is that I couldn’t stay for the fine Bradford curry afterwards as I had a train to catch.