Avian’s Blog

I've been missing a good function generator for a while now. Over time I've accumulated an assortment of various ad-hoc 555 oscillators and microcontroller hacks I've cobbled together whenever I needed to generate some kind of a signal to test a circuit I worked on. For a while I've been considering joining all of these in one box and slap some kind of an interface on top. I even bought a nice back-lit LCD display and some buttons for the front panel.

Then at one point more or less by accident I stumbled upon this low-end line of function generators from GW Instek and they looked cheaper and more versatile than what I was building myself. From what opinions I could find on the web about it they mostly appeared positive. Last week when it came in stock in this corner of the world I bought one.

After a couple of hours of playing with it I can say it's a perfectly functional instrument that as far as I can see works as specified. However as you might expect, the fact that it costs around 150 € less than the next cheapest arbitrary waveform generator definitely shows itself.

Interestingly, my complaints mostly have to deal with the user interface. For instance, the first thing I noticed is that there is no visual indicator whether the display is set to show signal amplitude for a 50 Ω or high-impedance output termination. Since this means a factor of two in output voltage level a wrong setting can easily be fatal for some circuits. I guess resetting to high-Z setting before turning off the generator would be a prudent habit to keep.

One thing that sold this device for me is the USB connectivity. After being spoiled by the equipment I have at work, I missed being capable of running some automated tests for projects at home. While the manual doesn't mention the word USBTMC anywhere, the remote-control commands look suspiciously identical to the venerable industry-standard GPIB language.

When I connected AFG-2005 to my computer, first thing I noticed is that it doesn't actually use USBTMC protocol. Instead, it's behaves like a serial modem with USB ACM interface. As far as Linux user space is concerned, this doesn't seem to make a big difference - both kernel drivers expose a simple character device for interaction with the device. For USBTMC I know that when the write() syscall returns, the device has already accepted the command and you can expect it will be giving the signal you programmed. But I'm not sure whether this also holds in this case.

The implementation of the protocol is somewhat buggy though. First of all, commands require a terminating ASCII line feed (\n) character, which isn't the case with USBTMC devices. Invalid commands are simply ignored - there are no error or diagnostic messages at all.

My device identifies itself like this for the *IDN? command:

GW INSTEK,AFG-2005,SN:EN810021,V1.11

It's quite easy to crash the instrument's firmware by feeding it malformed commands. In that case the front panel stops working and the only way to restore it back to normal is by using the hardware power button.

The front panel display itself is somewhat sluggish and if you issue a lot of commands through the USB it might take a while to catch up with all the settings, even though if you watch the signal generator's output you can see they are applied much faster. The multi-purpose knob has similar issues and if you turn it too fast the values start jumping around instead of going in one direction (this seem to be a common issue though - I've seen a lot of different devices have a problem with that).

Arbitrary function generator works nicely and can be easily programmed from a PC using a DATA:DAC command. What I don't quite understand is the syntax there. In contrast to other instruments I worked with, the manual says that the first argument is the Start address of the arbitrary waveform. It gives an example where this address is 1000, but that doesn't seem to work at all with my instrument. The only address where the ARB output works as expected is 0. Using other addresses I either get garbage output with no correlation to what I wanted to do or crash the firmware.

Arbitrary function generator has a 20 MHz maximum sampling frequency and firmware allows you to fully exploit that, even when the frequency of the signal exceeds 5 MHz maximum for pre-programmed waveforms. The results in that case are less than perfect of course. The most obvious problem is the significant DAC jitter. Here is how a square wave looks like at 10 MHz:

In conclusion, this instrument gives you quite a lot of value for its price. But unsurprisingly, it's not on the level of instruments that have a few zeros more on the left of the Euro sign. I can't stop myself thinking though that a lot of these problems would take a simple firmware patch to fix. If only the manufacturer would provide source and simple means of reprogramming.

It sounds strange, but analog FM wireless microphones (the kind you find in studios, theaters and soon-to-be-restaurants) are one of the obstacles in the efficient re-use of the UHF band that has been freed with the digital switchover. They operate in the same frequency band as the now silenced analogue TV broadcasts, but on the other hand have never been well regulated. While locations and frequencies of TV transmitters are well known, microphones can appear on a lot of different channels and practically in any location.

New devices operating in the TV white-spaces can't be allowed to interfere with them, so they either can't use frequencies where microphones appear (leading to unused spectrum) or they must detect them using spectrum sensing. Reliable and energy-efficient detection of wireless microphones at low signal levels is an open research topic.

To test different ways of detecting microphones, IEEE has come up with simulation waveforms that can be easily reproduced on lab equipment and are reasonably similar to what microphones transmit in real-life usage. They simulate a silent microphone, microphone used with a soft voice and microphone used with a loud voice by frequency modulating a sine wave with different baseband frequencies and deviations (described in this Word document).

For example, here's how a soft voice simulation looks like on a spectrum analyzer when transmitted by a big and expensive Rohde&Schwarz vector signal generator. This is a 3.9 kHz tone modulated using a 15 kHz deviation:

And this is the same signal transmitted with an USRP N210:

As I mentioned before, VESNA also has some signal generation capabilities. This is how it looks like when the signal is simulated using a direct digital synthesis algorithm and a 4FSK modulator on the CC1101 transceiver:

The order-of-magnitude in price difference in hardware shows itself well enough here as transmission from VESNA obviously differs quite a bit from the desired. But still it's good enough for some detection experiments and of course, you can't have a USRP mounted on every light pole.

Although I haven't yet done detailed measurements, VESNA's transmission actually does seem to comply with FCC's requirement regarding spurious levels for wireless microphones (but not with more stringent European ETSI regulations).

Last November I was writing about an issue with 2.4 GHz transceivers that were deployed on street lights as part of Jožef Stefan Institute's testbed for radio communications. Some radios based on Texas Instruments CC2500 integrated circuit seemed to degrade after they were mounted out doors. In the most extreme case, there was almost an -30 dB drop in receiver sensitivity and maximum transmit power dropped to insignificant levels.

The leading theory at the time was that some component has deteriorated over time due to environmental effects. After some initial testing it appeared that the coaxial cable between the radio PCB and the connector is to blame. However having more boards with this issue in the lab showed that in most cases it's not possible to restore original characteristics only by changing the coaxial cable.

I then fired up the soldering iron and did a brute-force approach: on three bad radio boards I manually replaced components one by one, preforming automated tests of the board after each replacement. While replacing the coaxial cable did have a small effect (0.3 dB in the best case), only replacing the CC2500 integrated circuit itself seemed to restore the correct performance. So the suspicion immediately fell on the transceiver chip itself.

Since I did not exhaustively test all radios for sensitivity and transmit power before deployment, I couldn't be sure whether the radios have been bad from the start or whether they degraded due to environment. The fact that only radios that have been deployed out-doors have had this issue pointed to the second explanation, but since more radios were deployed out-doors than in-doors that could have been a coincidence as well.

As a test, I also brutally heated up one of the newly replaced CC2500 chips with a hot air gun. After such test, the radio board had similar symptoms as the boards that were unmounted from the testbed as defective: the digital part of the IC still functioned correctly, but receiver's sensitivity dropped permanently by 33 dB. Unfortunately I did not record the temperature to see how much heating is actually required.

To test the other theory, I set up a long-running experiment on the testbed that recorded received signal strength between neighboring pairs of newly replaced radios 4 times a day between December 2012 and March 2013. If radios were deteriorating over time, I should be able to see the signal strength drop during these three months.

Here are two typical plots of these measurements over time:

As you can see, while there is a lot of variation in the signal strength, there is no obvious downward trend. Variation is probably due to weather and or large things moving around the radios (these are mounted in an industrial zone, so moving trucks and other such things are not an uncommon occurrence).

So, it currently looks like we either mounted already defective radios or they were damaged by a one-time event after deployment (which is hard to imagine). The fact that over-heating damages radios in a similar way may point to an error in manufacturing, although that's not a popular opinion, since these boards were soldered using a lead solder and radio ICs are supposed to support a RoHS process that involves higher temperatures. It's also a theoretical possibility that the radios were damaged during summer (the test above was obviously done over winter months), although again it's very unlikely that sun would overheat the radios.

Kindle's power supply (still talking about Kindle 3 that's been turned into a light-weight headless Debian box) is centered around MC13892. That is a power management integrated circuit (often referred to as PMIC in source code) specifically designed for powering Kindle's Freescale i.MX35 processor from a lithium-ion battery.

The chip itself hides under one of the shiny RF shielded enclosures and is connected to the main CPU over an SPI bus. The MC13892 datasheet reveals a very flexible chip that contains several configurable switching and linear power supplies, handles power on an USB bus and can work with a main and a backup battery. It also has peripherals like the real time clock, touch screen, temperature and light sensor interface and several programmable LED drivers.

Actually, it's interesting that Kindle 3 already seems to have much of the hardware needed to implement a touch screen and a screen with a front light even though these features only appeared in much later models. Also interesting to note is that the e-ink has its own separate power supply, so a lot of the MC13892 functionality appears unused.

Talking about unused functionality, MC13892 also has a Coulomb counter that can accurately integrate battery current to predict its life time. This also appears unused as the battery module itself seems to integrate a management circuit with an I²C bus. As far as I can see the built-in software actually uses information from that instead of MC13892. libgasgauge.so suggests it might be one of the Texas Instruments products.

Apart from curiosity, I also looked into this topic to find a most convenient way to power my Kindle without a battery attached. I'm powering my device from an outlet so it doesn't make sense to waste a perfectly good Li-ion battery by keeping it constantly connected to a charger.

However, as many people on the web with dead Kindle batteries found out, Kindle won't boot with no voltage on the battery connector. Looking into the supply tree in the MC13892 datasheet it's apparent that the battery voltage is the central point from which all other parts are powered. The datasheet also explicitly states that the MC13892 will not power up the CPU unless it detects a valid voltage on the battery, even if power is available from the USB interface.

Unfortunately, this check cannot be fooled by a high-impedance voltage source in place of the battery (I tried), which means that the only way to power it up is to provide a proper voltage source capable of around 100 mA at 3.0 to 4.2 V.

This led to me to make this tiny power adapter that attaches to the main PCB instead of the battery. It provides all the power for Kindle's main board which has another benefit of freeing up the USB connector for any future hacks (switching to USB host mode would be nice).

My random parts bin contained a small Nokia charger (recently donated as broken) that gives somewhere between 6.0 to 5.5 V under load. Unfortunately that's a bit too high for Kindle's battery input (absolute maximum rating 4.8 V). Instead of tearing the charger apart and adjusting its voltage feedback, I opted for a small low-drop regulator (also salvaged from a random piece of broken electronics) on the adapter itself to lower the voltage to 4.2 V.

I guess using a dissipative regulator like this ruins a bit the wonderful power efficiency of Kindle's hardware, but at a few tens of milliamps of typical current draw it hardly gets warm to the touch.

If you've been following my writings (or if you've been at my recent talk in Kiberpipa) you probably remember that the department of Institute Jožef Stefan I work for has built an out-door test bed for cognitive radio experiments. In practice this means 50 or so VESNA boards with my experimental spectrum sensing radio hardware mounted in weather-proof plastic boxes on public light poles.

Since June, when the first batch of VESNAs were mounted, something curious has happened with the radio hardware. 2.4 GHz transceivers based on the Texas Instruments CC2500 integrated circuit degraded significantly on receiver sensitivity and transmit power. In some cases to such a degree that they became practically useless for any research work. In fact, this was discovered when we could not explain experimental results we were getting from some of VESNA nodes and started doubting that our equipment is functioning properly.

Since this hardware has been exposed for several months to daily temperature and humidity variations (boxes aren't airtight) and the antennas are mounted externally, my first guess was that perhaps the antenna connector oxidized or the coaxial cable deteriorated.

Here's a plot of receiver sensitivity and maximum transmitter power variations for a sample of VESNA nodes. First five from the left have been mounted out-doors in the test bed, while the other six have been deployed in-doors in the Institute. All printed circuit boards are from the same batch, and hence have exactly the same hardware and approximately the same number of operating hours. 0 dB here means nominal sensitivity and transmit power.

It's quite obvious that nodes from outside have a significantly larger deviation from typical values. What's interesting is that transmit power and receiver sensitivity didn't change consistently, which as far as I can see contradicts the theory that this is due to some simple attenuation on the path between the transceiver IC and the antenna.

In fact, you have to replace both the circuit board and the short coaxial cable to the antenna to restore the original characteristics. This can only mean that both of these are responsible for the problem. Regarding the transceiver, I can't think of any environmental effect that would deteriorate a silicon chip inside a sealed plastic package in this way. I think more likely suspects are the balun circuit and the few other external passive components that might have absorbed moisture or got affected by temperature variations.

Recently I've been working on an automatic test harness for the spectrum sensing hardware I've designed at the Jožef Stefan Institute. It takes the form of a Python script that talks to a vector signal generator on one end and a VESNA on the other. It tests the receiver under different conditions and after a few minutes or so (depending on which tests have been selected) writes a nice report that includes characteristics like receiver noise figure, power level detector offset and linearity errors, local oscillator accuracy and so on, plus all the raw data in case it's needed to double-check the calculations.

Looking back, this should be the first thing to make after I got the prototype circuit boards on my desk. It would definitely spare quite a few hours of dull button pressing and note taking. Unfortunately even this academic environment is not immune to pressing dead-lines and sometimes it just makes more sense to go with the slow-and-certain way of manually doing things than opt for including software development in a task that will in all certainty save hours of work but might also explode into a week-long debugging session.

In the end however, the development went quite smoothly. Controlling our stack of Rohde&Schwarz instruments turned out to be surprisingly easy. Using the USB Test & Measurement Class under Linux is as complicated as reading and writing strings to a /dev/usbtmc3 character device (my Debian Squeeze system already included all the necessary kernel modules). The high-level interface is the same as the one used on the venerable GPIB and consists of plain human-readable ASCII statements that control various aspects of the instrument or return measurement results. On our equipment the same interface is also exported as a telnet-like service on an Ethernet port, but I opted for USB since my laptop only has one wired network interface.

With this setup it's now finally feasible to exhaustively test a pile of receivers. This will also give me some statistical data to see how various characteristics differ from one device to the other without the need to depend solely on data provided by component manufacturers. Definitely a good thing to have on hand when other researchers come knocking on the door asking why their theoretical calculations don't fit the measurements.

Above is one interesting result of these measurements: since these receivers are used for spectrum sensing, it's important to know how the power level detectors behave in different conditions. This is the result of a step-response test of the TV-band UHF receiver based on the NXP TDA18219HN tuner. This tuner has several stages of automatic gain control and the power level detector takes their individual gains into account when calculating the power at the antenna interface. While the turn-on response is nice and fast, it takes quite some time for the tuner to settle back and provide an accurate measurement when the signal source is turned off.

This a collection of test results for a narrow-band sub-1 GHz tuner based on the Texas Instruments CC1101 chip. VESNA spectrum-sensor application supports quite a few different configurations using this hardware. While the measurements above show a properly working receiver, so far the automated tests have already found several software bugs regarding the receiver configuration and one out-of-spec radio board.

As usual, the software used to make these graphs is available on-line under a GPL version 3 license in the SensorLab repository on GitHub.

Sometimes little, trivial things keep bothering me. For instance that mystery regarding the switching power supply for the OLED display. Tests have shown the unexpected drop in supply voltage doesn't affect the quality of the displayed image, so it's a non-issue as far as I can see. But I guess it's the matter of engineering pride to find out what exactly has been going on. Recall that I've blamed a 4.7 µF chip ceramic capacitor from Murata to have less capacitance than it should. Well, I've been wrong.

For the production run of the Arduino OLED shield I've ordered another roll of capacitors, this time from Multicomp. The power supply circuit using them however behaves exactly like my prototype. Getting two bad shipments is just impossible I guess, so my brilliant deductions in that previous blog post must have gone seriously wrong somewhere.

To answer the capacitance question I rigged together a simple 555 timer circuit and measured capacitors from both batches using two methods: first by using a current-source and calculating the capacitance from the voltage time derivative, and second by measuring the time constant in a RC relaxation circuit.

Murata capacitors yielded 3.5 µF using the dU/dt method, Multicomp capacitors yielded 3.3 µF.

Murata capacitors yielded 5.1 µF using the RC method, Multicomp capacitors yielded 3.9 µF.

Now these home-grown measurements are nowhere near exact of course, but some back of the envelope estimates show that the declared value (4.7 µF with up to -20% tolerance) can most certainly lie within the error margins and my initial estimate of 1.4 µF doesn't.

So, if capacitors can't be blamed for the inconsistency, what can be? One of the wrong assumptions I made was that the switching power supply can provide at most 60 mA. That's certainly wrong as a simple experiment showed that in short-circuit it can source close to half an ampere. Investigating further it turned out that I didn't properly account for current regulation delays in the control IC and core saturation when the switcher is operating in such extreme circumstances.

In conclusion, now my opinion is that the initial measurements were correct and that in the pre-charge cycle the display indeed does sink a considerable amount of current. The fact that the results of that add-a-known-capacitance trick fit so well with the theory at the time must have been just a coincidence.

I'm still occasionally playing with the OLED display on the Arduino. It's a fun pass time to see what you can squeeze out of the Arduino's 30 kB of ROM in terms of graphics, animation and silly games. Plus the SEPS525 controller is in some ways similar to what old home computers from the Commodore 64 era had, offering some simple hardware features like scan line mirroring and framebuffer windows.

Anyway, while tweaking the software I noticed two problems with the shield: First, a white pixel in a row full of white pixels is somewhat darker than a white pixel in a row that is only half-lit, and second, when displaying some patterns the LM2703 micro-power switcher that provides the high-voltage supply starts emitting a high-pitched sound.

Since it's usually a bad sign that you can hear a switching power supply that is designed to operate in the megahertz range, I suspected that those two issues might be connected.

After hooking up the circuit to an oscilloscope and displaying a few test patterns the first thing to catch my attention were these spikes on the 14 V power supply provided by the switcher:

The upper, blue trace shows the power supply output voltage and the lower, yellow trance shows the power supply input voltage.

The picture above covers the time it takes the display to scan about 12 rows of pixels. The controller drives one row of pixels at a time and test pattern I used here was a black screen with every fourth row completely white. You can see when the controller hits the white row since the power consumption increases, which in turn increases the power supply's switching frequency and causes a voltage drop on the power supply input.

The weird spike happens when the driver goes from a black to a white line. Some further tests confirmed that, with the spike getting even larger if a black line follows several white ones. There is no spike on the black-to-white transition. The maximum voltage drop I saw was around 1 V, which is completely out of tolerances for this power supply design. What is happening here?

Here is a similar picture with a smaller time scale. The blue trace still shows switcher output. Ignore the yellow trace, which is voltage on the switcher's coil. It looks like the OLED display draws a lot of current for a small period of time, causing a large drop on the output capacitor voltage. After it stops, the switcher works continuously to get the voltage back to the correct level, overshooting a bit in the end due to delays in the regulation loop.

I can't measure currents directly on the PCB, but since I know the capacitances and the first derivative of the voltage I can calculate it. Given the 4.7 µF output capacitance, plus two smaller 100 nF capacitors at the display pins, these voltage ramps correspond to a peak discharge current of 1.5 A and an average charge current of 200 mA.

These results are weird. The display's datasheet lists maximum operating current on the 14 V power supply as 32.8 mA (although they might mean the average current). Even more confusing is the second result. The switcher is designed to provide a maximum of 60 mA to the output capacitor and given the components it's simply impossible for it to supply more than three times the rated current.

Time to recheck the assumptions. The first suspicion fell on the output capacitor. If its true capacitance was smaller than I thought then the calculation above would give a result that is too high. Changing the capacitor on the board for an identical one from the same reel didn't significantly change the situation. I don't have equipment to measure the capacitance directly, but by adding some other, presumably known, capacitance in parallel to the suspected output capacitor and repeating the same measurement with the oscilloscope I was able to calculate it's true value.

It turns out that this 4.7 µF chip ceramic capacitor in fact only has around 1.4 µF (the other one from the same reel I replaced had 1.2 µF). Using this capacitor value in the first equation the switcher current also matches the design calculations, which confirms this calculation was correct. I re-checked the part number and in fact these should be 4.7 µF with a -20% tolerance. The ramp on the picture above has a time scale on the order of a few tens of microseconds. These SMD capacitors should go to 100 MHz, so that shouldn't be an issue either.

Who is to blame here? Bad case of quality control or a mislabeled component reel? Since I soldered these myself by hand I can't claim the capacitors have been through the correct temperature profiles, but this would be the first time I would consistently destroy such ceramic capacitors by soldering. I will order equivalent capacitors from some other manufacturer and see if those fare any better.

With the corrected capacitance value, the current spikes come at about 450 mA peak. They are probably caused by the OLED pre-charge cycle and SEPS525 controller design. While I can't know exactly how the chip works, I do have some speculations on how a row- and column-driver design could cause this behavior. In any case I can't do anything about it, but a proper output capacitance should even out the power supply current and stop the audible noise. Even with these bad capacitors I don't think the shadowing effect is caused by the power supply. The voltage regulation is otherwise within tolerances and these drops occur only on transitions to black lines, where they can't cause those visible effects. Much more likely the artifacts are caused by voltage drops in the driver IC itself and again outside my control.

Update: Above conclusions are most likely wrong. See my follow-up post.

I mentioned energy detection and spectrum sensing before. The idea is that you try to detect if any radio transmissions are present in your neighborhood by simply detecting the energy the transmitter emits into the electromagnetic field. This is the most basic way of detection - any signal must carry energy. It's also the most robust as detection doesn't depend on the sensor knowing any details about the transmission.

There is a catch, of course. Parts of your own detector are unavoidably emitting radio frequency energy as well. Anything with a temperature above absolute zero has various charged particles moving in random ways which emit their own electrical signals and this thermal glow effectively blinds you for weaker signals. By definition the energy detector can't distinguish between a valid transmission signal and random noise.

With some statistics however you can still probabilistically detect signals that lie somewhat below the noise floor. The more accurately you can model your own noise, the weaker signals you can detect and higher the probability of correct detection. This is why I tried to find a good statistical model of the noise present in the spectrum sensing receiver I designed at the Institute.

Perhaps not surprisingly, I found out that the characteristics of the noise slowly change with time, which complicates things a bit. In electronics if some property is slowly changing it's usually connected to changes in temperature. The TDA18219HN tuner I'm using has an integrated die temperature sensor, so it was a straightforward experiment to check how the average noise level changes as the silicon heats up or cools down.

Graph above was measured with no input signal (with a terminator on the antenna connector), at 1.7 MHz channel bandwidth. It shows another surprise - the noise level actually decreases with temperature! This result is suspect, as noise usually increases with temperature. For instance, in this temperature range, the thermal noise of the terminating resistor alone would increase by 0.4 dB.

Obviously some other effect is at play here, so I repeated the same measurement, but this time with the receiver directly connected to a signal generator. I set the generator to a constant sine wave with an amplitude around 20 dB above the noise floor.

As you can see, this signal shows a similar decrease in measured power. So obviously it's not the noise itself that decreases with the temperature but the sensitivity of the receiver itself.

At this moment it's hard to say which parts of the receiver are responsible for this. It might be the many amplification stages or the power detector itself. Also interesting is that noise amplitude is falling faster than the amplitude of an external signal (approximately -2 dB change versus -1.5 dB over the measured range). I would expect just the opposite, as the increase in thermal noise should counter the loss of sensitivity.

In any case, most likely I can't do anything about this at the hardware level. The noise model will simply have to either compensate for the die temperature or only be valid after the receiver heats up.

As a side effect of a project I am working on at the Jožef Stefan Institute I have a USRP N210 on my desk. Together with an expensive stack of Rohde & Schwarz lab equipment it made for a fun pass time today after work hours while waiting in the office for the rain to stop. It is also an interesting subject for an investigation into those pesky practicalities of software defined radio.

It seems a lot of people forget that any software defined radio still depends on an old-fashioned analogue RF front-end. While the digital signal you feed to it might be perfect in every way, once it passes from the digital into the domain of D/A converters, mixers and amplifiers it is still vulnerable to non-linear effects, saturations and other such worldly imperfections.

In the case of this USRP, the first experimental transmissions we did with it were a quite awful sight on the spectrum analyzer, with the desired modulated signal merely 20 dB above a sea of spurious emissions spanning most of the RF front-end's 40 MHz bandwidth. After a bit of tweaking of signal amplitudes and RF gains though, the transmission did get into a somewhat useful territory.

It's interesting to see what happens when a single, constant-wave sine signal is fed to the USRP on the digital baseband interface as the spurious spectral lines that are produced offer some insight into what's happening behind the scenes in the RF front-end.

In the video below, the USRP N210 was fitted with the SBX daughterboard which was configured for 600.50 MHz central frequency and 0 dB RF gain. It was connected to a PC running GNU Radio software which was producing a quadrature signal with the frequency of around 100 kHz, amplitude of 0.5 and a sample rate of 1 Msample/s. In the first part of the video I varied the frequency of the baseband sine wave while in the second part I varied the ratio between the amplitudes of the I and Q components of the quadrature signal.

Signal analyzer was centered at the same RF frequency as the USRP, with the span of 500 kHz (50 kHz per division).

The highest peak on the screen, at around -50 dBm, is the desired signal. Everything else above the noise floor is unwanted. The most obvious of these spurious emissions is an image signal at minus the desired frequency and some 40 dB below it, and a third harmonic at -3 times the frequency. Image signal is usually a sign of bad image rejection in the mixer and the harmonic is probably created by non-linearities somewhere in the pipeline.

An interesting thing to notice is that the local oscillator (the peak that doesn't move) isn't at the center of the frame, but 6 kHz lower. It's hard to notice on this video, but the desired signal is actually positioned correctly, which means that the signal frequency is finely adjusted before the final mixing to account for this offset, either in the digital or analogue domain. Local oscillator is likely based on a fractional-PLL, which of course doesn't have infinite precision but can only be tuned in discrete steps, a fact that is hidden from you in the GNU Radio interface. This offset differs when you change the RF frequency and disappears in round settings (for instance 600 MHz), which confirms this theory.

Another interesting result happens when I mess with amplitudes of the I and Q signals on the digital side. As expected, another image frequency appears. But since this imbalance appears on the digital side, it is mirrored around the true central frequency and is offset from the image produced by the local oscillator by twice the 6 kHz offset. It even mixes somewhat with it in a non-linearity somewhere and produces a small spike on the other side of it.

The building I live in has very old electrical wiring and doesn't have safety grounds in the wall sockets. When I moved in I connected all ground pins of Schuko sockets to the neutral wire. My computer is powered from such a socket as well as anything electrically connected to it, so all devices share a common ground point. This ground however is above the real ground potential because of the voltage drop on the neutral line from all the electrical appliances in the building.

I also have a TV receiver connected via HDMI to the computer and that is connected to a coaxial cable from the cable TV system. The cable system as it turns out has a different grounding point, which means that current flows between the TV antenna connector ground and the Schuko ground pin.

This is annoying since it causes mains hum in my speakers and makes it possible to hear my neighbor's washing machine ramping up RPMs from the interference it causes on the ground line.

Today I finally found time to make an end to all of this and made a galvanic isolator for the antenna. I took the coaxial cable, cut away the original connector and replaced it with this hand-crafted thing:

I isolated the ground ring from the connector's metal body via strip of insulating tape and bridged the gap with capacitors. I didn't have 10 nF 500 V capacitors handy, so I used two 5.6 nF in parallel. The only problem I had was that the shield of this coaxial cable is from an alloy that can't be soldered, so I just tightened the clamp around the exposed braiding. The core wire was made out of copper though, so there were no problems soldering that to the central pin through another pair of capacitors.

If you have similar problems, there is a nice web page that explains all the different approaches you can make when isolating an antenna connection.

A while ago Gašper gave me this Energycount 3000 kit from Voltcraft for logging household electrical energy usage, with a wish that he would like to access its measurements from a computer. All this time it's been mostly gathering dust on my desk, but last week I've found some time to give it a closer look and made a few discoveries that are worth reporting.

The box contains two sensors that can be connected between a wall socket and a plug and a tiny battery-powered remote control for reading out the data. The short instruction leaflet explains that the sensors broadcast their measurements through radio every 5 seconds. With a push of the SCAN button you can set the remote control into a 6 second listening mode which catches the transmission and displays it on the small LCD screen.

The remote also has some calculation functions, like predicting the next electricity bill, but is otherwise nothing more than a remote display for the sensors, which apparently do all the logging. This makes sense: the remote control is limited by its batteries and as much functionality as possible is pushed to the wall plug where there is abundant power. The radio link is also obviously unidirectional. The sensors transmit their periodic reports and the remote receives them. All user interaction with the sensor is done through a push button on the sensor itself.

To get the data from the sensor it appears that all I would have to do is to eavesdrop on the transmission. Unfortunately, the box says this device operates on the 868 MHz ISM band, meaning that my 433 MHz receiver was useless. I could get a 868 MHz receiver module for it, but I suspected that these devices use something more complicated than on-off keying, so I looked for other possibilities.

Here is how sensors and the remote look from inside:

As you can see each device has two integrated circuits under a blob of epoxy. I'm guessing one is a microcontroller and the other obviously some kind of integrated ISM band transmitter or receiver. In both the sensor and the remote control they are connected with 5 copper traces. Having recently encountered and worked with chips like the CC1101, my first guess was something like that. I figured the five traces would carry a digital bus like SPI or I²C, so I soldered some wires to the tiny traces on the remote (destroying one of the termination capacitors in the process) and hooked it up to a logic analyzer.

Unfortunately, what I saw there didn't look at all like a synchronous transmission. Out of 5 lines, 2 seem not to carry any useful signals (all I saw there were some transients that looked like glitches). The remaining 3 might act as a digital bus immediately after the microcontroller wakes up the radio chip, but otherwise look like some pulse-width modulated signals for the majority of the 6 seconds when the radio is turned on.

This was a sort of a dead-end until I came across chips like the TH81112. These are ISM band receivers that can be used to receive ASK or FSK transmissions, but are much simpler that system-on-chip products like CC1101. They merely contain a tuner, intermediate frequency and a phase detector and therefore rely on the microcontroller or some other logic to do full FSK demodulation. In hindsight, it makes sense for Energycount to use something like this. It's a relatively cheap product and an expensive general-purpose transceiver like the CC1101 would probably be far too expensive for it.

Update: Gašper found a thread that has some interesting insights, particularly regarding the communication between the radio chip and the CPU. It's possible I was looking at the signals at a completely wrong time scale.

But at this point I didn't bother to mess further with the original receiver. I started up GNU Radio and Fun Cube Dongle Pro and tried to catch the transmissions with that. It turns out fishing out the correct channel in the 868 MHz ISM band is a challenge in itself if you're only limited to the 90 kHz bandwidth of the Fun Cube Dongle. But luckily having the transmitter and receiver close by meant that I was able to see the transmission burn through even when the receiver wasn't tuned exactly to the correct frequency. So after some bisection I found the transmission at 868.388 MHz.

The double peaks in the spectrogram gave me more confidence that this is indeed frequency-keying with 20 kHz deviation and with GNU Radio's FM demodulator block the bits in the packets became clearly visible.

Actually, it's impressive how easy software defined radio makes tasks like this. Throwing blocks around in the GNU Radio Companion in a few minutes is something that would otherwise take you weeks with a soldering iron. Next time I'm doing something similar I'll most likely skip the whole logic analyzer part and just skip right to sniffing the radio waves.

To conclude, this demodulated signal is now something that can be piped to the capture process from my AM433 project and it will hopefully produce binary data. But of course, getting useful information from a binary blob is a whole new matter and that will come in a follow-up post.

Here are a few more notes about the 433 MHz super-regen receiver module I've been previously writing about.

I'm trying to make a multipurpose USB-connected receiver for packet transmissions from various sensing devices, like cheap weather stations. For this purpose I attempted to digitize the demodulated signal from the receiver with a USB connected audio interface and write some decoding software on the PC.

It turns out that my first, successful tests of this receiver module on a protoboard were just a lucky coincidence. While the sensitivity and range seem to be exceptional, that also brings a lot of trouble. It's incredibly difficult to avoid interference from near by devices. In one case, for instance, that turned out to be a nearby idle switch-mode phone charger. Running this receiver in the vicinity of (or even powered from) such a lively source of RF energy as a high-speed USB device proved to be especially challenging. The receiver is not very selective, so a very broad range of RF frequencies can trigger a spurious signal on the output. One particularly puzzling example is when I get a 50 Hz signal on the demodulator output when the device is powered from USB and my oscilloscope ground is connected somewhere in the circuit.

When trying to solve this problem I've also stumbled upon the apparently well known fact that multiple super-regen receivers will interfere with each other if they are close by. Apparently the oscillators in both receivers will affect each other and you get impulses on the outputs of both.

Anyway, this is prototype board I'm currently working on:

There's the USB interface on the left and the receiver module on the right. What would otherwise just be a couple of straightforward connections between two circuit boards is now a mesh of filter capacitors and resistors. PCB design guidelines for reduced EMI PDF document from Texas Instruments has a good overview of the techniques I used.

I took special care for proper grounding. The other side of the board is a solid grounded copper fill. +5V supply from the USB goes through two RC filters as close as possible to the connector to minimize any length of wire that could act as an antenna. There are additional blocking capacitors as close as possible to the RF and AF parts of the receiver module.

The demodulated signal line has similar RC terminations on both ends to prevent emissions.

The USB part will be completely covered by a grounded metal RF shield. It's the only part that still needs to be done. As it is the receiver still receives mostly interference from the USB bus and I'm hoping the shield will take care of that. If not and it turns out the interference is going out through the wires, I still have a few SMT chokes that might do the trick better than the RC filters I'm using now.

A while ago I was invited to participate in Farnell's product road testing initiative. I'm a semi-regular customer of theirs and the idea seemed interesting, so I chose a pair of 433 MHz transmitter and receiver modules to test and review. It's something I wanted to play with since I threw a scrapped weather monitor into my parts bin. The modules arrived last week and I found some time to try them out.

These particular modules are RF Solutions AM-HRR3-433 and AM-RT4-433. They are hybrid circuits built on a ceramic substrate with SMD components and are equipped with 100-mil spaced pins (something of a rarity these days and quite convenient for quickly testing ideas). They are meant for simple digital remote control or telemetry using 100% amplitude modulation on the industrial 433 MHz band.

This receiver is super-regenerative (they also have super-heterodyne receivers that trade low price for somewhat better sensitivity and selectivity). The datasheet mentions the lack of any tunable components which means they are pretty much usable out of the box. The inductor on the receiver is laser-trimmed - you can see the dark trim line at the top-center of the (larger) receiver module where a laser cut adjusted the length of the coil. The receiver works on 5 V and sinks around 2.5 mA of quiescent current.

As the datasheet promised, the receiver went live at the first try, even on a protoboard with its less-then-stellar RF properties (the thin ceramic substrate did get me worried though that pushing the pins too hard might break it). The manufacturer advises against using protoboards, but apart from that doesn't specify any particular bypass capacitor or layout requirements. Not surprisingly perhaps, since there are basically just four connections you need to care about: supply, ground, antenna and demodulated output. Just to be sure I used a 47 μF electrolyte and a 100 nF polyester capacitors on the supply lines.

My first experiment was with the weather monitor I mentioned earlier. This is very simple telemetry, carrying a few tens of bits in a burst at around 500 Hz. The picture below shows the modulation input to the monitor's transmitter on the upper trace and the demodulated receiver output on the lower trace.

The receiver will also catch for instance the transmission from my car keys (a somewhat more compressed burst of a few hundreds of bits at 2 kHz):

Or any number of other of transmissions for which I have no idea where they originate from (although this page gives a few pointers in identifying the devices that transmit them). At least in this residential part of Ljubljana it seems this is a pretty crowded part of the spectrum.

A robust error detection and/or correction certainly looks like a must for any kind of communication here. Basically all those devices are communicating on a shared channel and depend on the fact that other devices only transmit for a small time interval and collisions are rare and detectable.

So to conclude, at £10.31 (a bit under 12 €) the receiver module certainly looks like a good bargain for anyone that doesn't want to get their hands dirty with their own RF circuitry. The TTL-compatible output makes it trivial to interface it to digital circuits and receiving telemetry from wireless devices like my weather station is just one microcontroller and a Manchester decoding routine away. Also beyond tinkering with one-off projects I don't see many cases where you would want to roll your own instead of using a finished module like this.

As you can see I only touched the receiver at the moment. I'll try a few experiments with the transmitter next. Now that I have a verified working transmitter/receiver pair I definitely plan to also check some of my own receiver ideas.

Kiberpipa is extending its season well into June so I'm pleased to announce that there will be another talk next week for electronics enthusiasts, continuing the series I started in January.

This time the talk will depart from the details of small signal electronics and instead focus on the problem of powering those circuits on the go. If you are designing a mobile device there are good chances it will be powered by a rechargeable battery. And even with today's fully digital devices battery management remains a stubborn island of analog technology.

New cell chemistries are constantly in development and old ones are continuously improved by new methods and materials, being motivated in part by new electric-powered vehicles. Different chemistries can dictate very different designs of circuits that are powered by them. So we will discuss the battery technologies in use today, their individual strengths and weaknesses and what development we will likely see in the future. You will also hear about specific charging and discharging techniques and how to avoid the most common mistakes.

The talk will be held this Tuesday, 7 June at 19:00 by Gregor Maček, electrical engineer and entrepreneur, designer of eCAT line of electric vehicles.

The talk (in Slovenian language) will be streamed live and recorded by Kiberpipa.