Function generator repair

I have TTi TG330 function generator that I use every now and then. It is fairly nice device, capable to frequencies from 0.003 Hz to 3 MHz in sinusoidal, trapezoid or square waveforms, including sweeps and 120MHz counter. I do not need it every day or even every week but when I do, it is worth every single cent of its price.

Unfortunately it broke a while back. Turning it on did absolutely nothing. I checked the main fuse but no, it was okay. So time to take it apart and see what is going on then.

Its a bit difficult to tell from the picture but the top cover has turned slightly yellowish near rear. Generator is fairly warm during use so that isn't exactly surprising.

Covers are held by simple plastic locking tabs instead of screws. Take these off from corners and cover comes handily off.

The insides. Note that generator is shown here upside down; the board seen on bottom is actually towards the top of the cover in normal orientation. I'm not exactly happy about that large and heavy transformer hanging in there during normal use.

All the capacitors seem to be okay, so it was time to start probing the board. It did not take long to find out that fuses, circled in picture below (marked FS1 and FS2) both seem to be blown. Weird, considering that main fuse (earlier in power supply chain) was intact.

These fuses are on secondary side of transformer so there should not be any (very) high voltages there, but one still must be very very careful when probing around these devices. Even when powered off there might be dangerous voltages around.

I could not find schematic for this model, but I did find schematic for model 550 which, while different, suggested that these fuses might be 500mA (if my memory serves, this was few weeks back now). Not something I had handy, but a quick trip to Sp-Elektroniikka (local parts store) I was able to acquire suitable SMD replacements. The space is a bit cramped but I was still able to replace these fuses with little trouble.

Since the original fuses were both blown I was a bit suspicious if this would work; if there is some issue further down the chain, new fuses might blow again immediately.

They didn't, and generator seems to be working fine again.

So I put it back together and it is serving me well again. No idea why those fuses have blown, but as long as it doesn't happen again I am happy. Although I do not keep the generator on 24/7 anymore.

Testing linear regulators

Recently I was testing few different regulators and how they behave when you inject higher voltage (at low-ish current) to their outputs than what they are supposed to regulate. As it turns out (and as I kinda expected), many regulators are not very happy about this.

Testing them was kinda fun though. Let's take this 5-pin, 2.9x2.5mm sized one, very cheap 5v micropower (30mA max) regulator IFX20001;

That board is with standard 0.1" (2.54mm) grid. That should tell you about the scale here.

This one requires fairly large output capacitors to be stable (over 3.3uF), so I used 2 2.2uF caps in parallel. Those output caps are almost larger than the regulator itself! And of course I added small  (100nF) input cap.
Positive supply wire goes to left, ground to right and output downwards.

Unfortunately injected voltage goes straight to output with this chip (even if limited to well below 10mA) so this chip doesn't work too well for me here.

Another one I tried came in 8-pin 0.65mm pitch package. That does not fit very well on this prototyping board, but fortunately I keep old unpopulated project boards handy for just this kind of purpose. There is usually a part of them that can be used for just this kind of hacks;

I think this was originally for LED driver chip that I found out I don't really need so it was taken out from newer board revisions.

Here leftmost red wire is supply, center one is output and rightmost is voltage injection test lead, through 2k4 resistor. Resistors on left are feedback (with wire on top of chip being feedback wire), capacitor on left output capacitor (same 2.2uF as I used above, I do have full reel of them!) and wires on top are ground.

Neither of these chips was too happy to have higher voltage injected to their outputs, latter behaving a bit better. So if there is a risk of that, there needs to be diode in series to make sure nothing bad happens. Unfortunately I need output voltage to be 5v or slightly above so otherwise nice and smaller IFX, with its fixed 5v output voltage, does not work here. Ah well, so I spec the adjustable, larger and slightly more expensive other one.

Spec for what? Sorry fellas, but that is something I am not willing to share at this time.

Bluetooth headphones, once again

Some time ago I wrote some thoughts on bluetooth headphones for phones.

I've gained a bit more experience since so I think it's time for an update.

I actually use several bluetooth headphones and/or hands free-sets;

- Ancient Jabra BT620s. Old (one might say "ancient", technology-wise) but still work nicely. These I use mostly in office when I am anticipating a long call or when I want to use both hands when in phone.
On minus side, they're fairly large yet they offer almost no external noise reduction, so I can't really use them when biking, lawn mowing or anything. The worst part of them is stupidly bright flashing blue light that apparently can't be turned off. Since that makes me feel like I'm having big flashing "look at me!" sign on my head, I very rarely use them in public. They do look a bit stupid even without the light, but then again, I am not a fan of this kind of "on the ear" headphone design anyway.
Battery life is pretty good, I don't think I've even ran out, but then again, due to the appreance issues I don't really use them that much.

-Car 1 handsfree (2011 model, factory option Blaupunkt radio). This actually works damn well. Only problem is annoyingly loud "connect"/"disconnect" sounds when getting in or out of the car, but that is just minor issue for otherwise well working system. Damn steering wheel in that car has more issues than the bluetooth setup! (fortunately it's just radio/phone buttons on steering wheel sometimes refuse to work until car has been power cycled, and not main functions of steering wheel)

-Car 2 handsfree (Pioneer aftermarket set.)  For phone use it's okay, main shortcoming being mostly the microphone that doesn't seem to be very sensitive. When trying to listen audio (podcasts, music etc - non-phone usage) from phone sometimes doesn't come through, and only way to fix this is to power cycle entire car (turning just radio off with power button isn't enough). Kinda weird that hands free doesn't seem to be affected by this issue.

-Previously mentioned Procaster BT-01 unit. In general it works quite well, and the main issue I have with it is that when the "battery empty" indication sounds, there really is maybe a minute left, making that warning pretty much useless. Since I'm primarily using them along with hearing protectors when doing noisy work, I'm seriously considering next hearing protectors to be ones with built-in bluetooth.

-Philips SHB5900 earbuds. In essence, earbuds connected by wire (that goes behind your neck) that has control and battery bulges in it. For what should be quality brand these are real disappointment. Battery/control pods are large and heavy enough so that they get caught on shirt collar, or pull earbuds off just with their weight so I have to be constantly re-seating the buds in my ears (granted, this happens more or less with all earbuds so my ears might not be best for them).
The bluetooth connectivity is pretty bad too. For some reason whenever I look directly left the audio completely drops out. Looking right isn't an issue. Where the phone is (right pocket, left pocket, backbag) doesn't seem to matter. Pretty annoying when biking.


Now, in general, the battery usage is the main issue. Smaller units (BT-01 and SHB5900) have some 4 hours battery life, some units even less. Depending on your usage that might not even last a full day (I certainly run out of battery way too often when doing some light work outside.)  While charging is relatively fast, it's still annoying if you have to do it constantly. Not that many people listen anything for entire day but some certainly do. And if you forget to charge the battery, next time you might have maybe hour left. This has happened to me many times, especially with BT-01, due to its longer nominal (possibly 6-ish hours) life. "I used it for just two hours, no need to charge" .. except that I didn't charge it last time either, and now there's less than hour left.

The second issue is actual connectivity. Philips is supposed to be one of the better brands but in this regard it sucks with audio constantly being interrupted momentarily. BT-01 seems to have somewhat better radio but even it staggers occasionally. Jabra - surprisingly, considering its age - seems to be best in this regard, I have only very rarely noticed any breaks in audio.
Car units don't seem to have this problem (maybe because phone and radio don't really move related to each other so link is more stable).


Then there is the audio quality with all kinds of codec combinations which I can pretty much ignore. When using these I'm pretty much never in situation that could be described "quiet listening" so slight degradation in audio quality is absolutely no issue. And I'm listening mostly podcasts and such anyway where quality loss isn't that noticeable.

On plus side, lack of wire is a good thing, especially when working. Until you run out of battery. Sometimes several times a day.

All in all, my verdict:
If you are what I'd call a serious listener (or even audiophile), there is no usable wireless headphone set. Quality loss and interruptions in audio are absolute no no.

For a physical worker - get rid of wires, now, and get a headphone set with big battery. Lack of wires that just get on your way is definite improvement.

For light use - occasional listening - wireless earphones are okay, but then there is the issue of keeping them charged. Forget once and suddenly you can't listen anything the next time. Depending on your habits the trade-off might be worth the risk.

And just to poke at this specific beehive;

Should you get a device that lacks headphone plug? That's easy: absolutely not. I feel that the cost introduced by headphone batteries, connectivity issues and audio quality is far too great for losing option of using any commonly available wired set. Wireless as an option is great. As an only option? Just no. (and no, converters/dongles in this context only add one fragile extra component to the mix. Connectors are already the weakest link (both proverbially and literally) and you want to add two more to the chain? Come on now.)

Led-lamp post mortem

It was to happen sooner or later. First LED lamp we've used pretty much died. Not completely, but it started to turn on and off randomly (not exactly flickering as it kept on or off for longer periods) which was annoying enough so I took it off and replaced with a new one.

Here it is. No-name brand, but I've taken a habit of writing date and place of purchase on the lamps (well, LED and CFLs, you can see tails of text on glass at left) when I put them in use. The date on this was march 2013, so I got about three and half years of life out of it. Of course it's out of warranty by now.

I have no exact figure but I guess this might have been used maybe four hours a day in average, which would put it around 5000 hours or so total. Not exactly a great figure for a LED lamp, actually. However the actual figure might be double that, too, I really don't know for sure as I haven't really kept record of lighting usage at home.

 
Being a curious person with some time on his hands I decided to see what's inside.

First problem is of course how to open it. After some unsuccessful attempts with a knife (round objects like this and knife is kinda dangerous combination, one slip-up and there will be blood...) I put it in vice grip and just grabbed the glass (with thick gloves on, naturally) and twisted. Something gave - and it turned out to be transformer coil and plastic mounts inside. 

Although the glass and heat sink look and feel like plastic, they actually are glass (as I found out when I tried to twist it off - I survived that breakage without damage) and aluminum. The heat sink is anodized so just probing it with multimeter doesn't work (and your fingers should be safe when it's on, but I wouldn't touch it anyway when on), but if you scratch the oxidation layer off the bare metal is exposed)

The main board, with transformer placed in its usual position again. The "isolation slot" there is pretty much for show only, it doesn't really isolate anything; you can see leads going to led under the transformer coil there. Any high voltage isolation here happens purely inside the coil, and since I have no means to judge the construction I can't really say anything about that.

Although it is difficult to see from picture, the flux residue on board is pretty bad. There's nothing obvious that would explain its failure though. Caps haven't leaked or swollen either.

The chip in the middle is LNK613, which happens to be purpose-made CV/CC controller. Rest of the board (and LED board) are pretty much exactly the same as the example given in chip datasheet (no surprise there), and I didn't feel like analyzing it in detail so nothing more about that.

Led board (metallic for heat dissipation) has resistor, capacitor, diode and the LED itself. So simply the parts needed to be on the secondary side of transformer by example circuit.

So this is what you might find inside a four-year old LED bulb. Not the cheapest construction I've seen so far, but not the best either. At the moment I'm waiting one of the dimmable LED bulbs to burn out so I could see what they've eaten... Although I don't expect much more than this, maybe with just a slightly different chip in the center.

About RF module selection (again)

Last time I mentioned working with WF121 WiFi module. This module is manufactured by BlueGiga (now owned by Silicon Labs) and costs around $17 at digi-key if you need just one. One might ask why I am using this module, instead of say, ESP8266-based module that costs maybe $7 at same vendor?

I've discussed about this in past posts already, but this is worth repeating, this time with a bit more concrete example, especially now with new related legislation (EU directives) in effect.

The short answer is: Declaration of Conformity. To sell your devices in Europe you have to be able to present one. And some categories - like devices dealing with RF - require fairly strict examination before that can be (honestly) produced. As you might guess that examination costs a lot.

I am making a specialized, relatively low volume product in Europe I plan to actually sell. The original R&TTE (Radio & Teleterminal Equipment directive, 1999/5/EC) already places quite strict requirements on radio equipment, and new RED (Radio Equipment Directive, 2014/53/EC) makes those even stricter.

Let's say the one device I make sells, say, 1000 units over its product lifetime.

If I use pre-certified module, I don't have to re-certify my design (RF functionality) as long as I use the module as-is, antenna and all included, so total cost of the module is $17 (actually less, after proper sourcing and volume discounts are in.)

If use use ESP8266 module that is not pre-certified (so far I haven't seen even single module that were certified in Europe, but feel free to correct me if you know one), I actually have to certify my entire design as radio equipment myself. This is not cheap process - let's say I get lucky and the cost of RF certification is about 20k€ ($22.3k with today's rate), but it might be even more.

Suddenly that cheap module costs $7 + ($22300 / 1000) = $29.30 !

Not so cheap anymore.

And that is why I pay a bit more for certified RF modules.While for example EMC/EMI examination is still needed, that is very cheap compared to RF stuff. And those I have to do anyway.

One might get away for a while for selling devices that only claim to have been certified, but especially with new marking rules of RED, you only need one person who checks your claims and you are in deep s**t. Trust me, you do not want to risk it.

On the other hand, if you are building a hobby project you do not intent to sell (or considering the ambiguity of the phrase used in directive, "bring to market", even freely give away in some cases), feel free to use the cheap modules, hobby use doesn't carry such requirements. But you still need to be sure that the $3 module from china isn't actually (un)intentional emitter (aka jammer) - people are not happy if you happen to mess with their frequencies and hobby use doesn't give you free pass there if you get caught.

Embedded debugging fun

Sometimes I forget how difficult crash tracking and fixing can be. And for once I would be really happy to have a step-by-step debugger handy. Unfortunately, for this platform I don't.

So I have this simple struct:

struct struct_wf_settings {
    unsigned short magic;        // A3F0: structure valid
    unsigned char mode;          // 1=sta, 2=ap, other=undefined
    unsigned char ssid[4][32];   // ap:first is name; sta:associated SSIDs
    unsigned char ssidPw[4][32]; // passwords
    unsigned char bssid[4][6];   // MACs
};

As you can guess, this is to control external WLAN module, in this case WF121. 

I have written code is written so that it compiles for several different devices, including WiFi module evaluation board (PC as host via USB port) and embedded board I'm using (with ARM processor as host). It works perfectly when ran or PC, but on embedded side it fails in following part (some irrelevant code omitted for simplicity, some debug stuff added).

... 

if (addNewAp) {

  // checking pointer to struct; it is valid.

  debugWriteInt("wfSet=", (unsigned int)wfSettings); 

  // n is slot; 0-3. In this case 0 as this is first to be added (yes, that too was verified)

  // print address to ssidPw used. This is correct.

  debugWriteInt("ssid p adx=", (unsigned int)wfSettings->ssidPw[n]); 

  // store ssid (kept in temporary buffer, typed char[66])

  cmemcpy(wfSettings->ssid[n], wfConnectTempBuff, 32); 

  // store password; also in same temp buffer 

  cmemcpy(wfSettings->ssidPw[n], wfConnectTempBuff+33, 32);

  // store bssid from event sent by module

  cmemcpy(wfSettings->bssid[n], buff+6, 6);

  // signal change to main 

  wfEvent(WFE_SETTING_CHANGE, 0,0);
}

... 

This is part of "Access Point connected" event handler, where we're figuring out where we actually just connected. At this point we've figured out that this AP wasn't previously known, so we add it to our table of APs we can use in future.

This crashes on second cmemcpy (ssidPw). After some checking I found out that it fails because the target address is invalid. Except it's kinda-sorta correct - the lowest 24 bits of target address is exactly correct, but the highest bits of (32-bit) address are now 0x61, causing processor to segfault when trying to access (nonexistent) memory area.

What the f***?

I'm using custom "standard" library here, and cmemcpy (so named to avoid namespace clash) is simple while-loop that does nothing but copy source from target byte by byte. Nothing fancy, exotic or optimized in such a way that could do anything insidious, and there is nothing overflowing, and it already has been used for several years without any issues (and yes, I know I should also be using sizeof() on call, but copy size isn't the issue here)

Note that second debugWriteInt; it prints out address of ssidPw slot I want to use. Address there is correct. Just a few lines later it isn't anymore.

I even tried to dig through disassembly but since I am not sufficiently familiar with ARM assembly this was a bit of a dead end. Nothing very obviously wrong though, and specifically no mysterious 0x61000000 added to r0 anywhere. A reference to [sp, #20] kinda stumped me; I'm guessing it refers to n variable but it was "a bit" difficult to figure out so I gave up (oh, did I mention that this is compiled with -O2 ?)

Unless this is a compiler bug (and quick googling suggested that there have been somewhat similar issues in GCC 4.7-branch, although on x86), I'm at a loss here. I'm a bit apprehensive on upgrading the compiler as it might cause other issues elsewhere. The devil you know, you know...

Eventually I just moved the first cmemcpy to end of sequence, and not the code works correctly. Not the first time code rearrangement fixed things. But I can't shake the feeling that there is a ticking time bomb there still... So it works correctly, for now.

And I don't like it.

Dead (cheap) monitor

Several years ago we got a cheap LG LCD monitor for one of the PCs. Now it died - wouldn't turn on no more. As this specific PC is pretty critical for our operations I immediately went and bought a new (also cheap-ish) monitor and just moved the old one to a corner, pending examination - either repair (not worth the trouble, really, considering the price and hours we already got out of it) or waste disposal (more likely).

Then, one day I had finished whatever I was doing and had some time until a customer dropped by. The time was long enough so I didn't feel like just browsing the net, but short enough that I didn't have time to start anything serious either. So I picked this monitor up to see if I could do something. I expected the reason to be the usual - dead capacitors.

The construction was typical; bezel was attached with nothing but clips, and I wasn't really that careful with them so unsurprisingly bezel was scratched at points. But it came off easily. It turned out that panel and electronics inside weren't attached to rear cover either - all the plastic just dropped off.

But wait, there's more! The main electronics cover wasn't attached to anything either - after taking covers off it, too, just lifted out! Well, after taking out backlight wires. Damn, this really is the cheapest construction I've seen yet. 

Insides of the electronics cover. Left is power board, and that tiny, about credit card-sized board is the actual driver board. I was expecting a paperback book-sized board so this came as a surprise.

There wasn't anything obviously broken either. The fuse (grey tube next to power connector) was ok and all the caps seemed fine so I was thinking what to do next when I ran out of time - the customer I was expecting arrived. Which also is the reason I don't have more (better) photos of it.

Considering the current value of this monitor (maybe few tens of euros in working condition) I decided it was not worth further troubleshooting and just quickly re-assembled it (carelessly, so all the parts aren't sitting right) until I could dispose it properly.

Blown to high heavens

I just came up with this gif video which reminded me of something I heard once. No idea if this ever happened but it is a kinda fun and a bit educational story nevertheless.

Some road workers around here had their asphalt machine repaired. Specifically, the burner of the tank that holds the bitumen material before it is mixed to become asphalt. This is a pretty big tank, almost 10 qubic meters (or about 350cubic ft) in volume, typically full of very hot asphalt material. As you can guess, keeping this stuff hot takes a lot of energy and the burner that keeps is hot is quite powerful.

Now, this time, after the burner repair, someone decided to do a test run. With the tank completely empty.

Not a good idea. Just a few moments after the burner was turned on the tank lid brew off. No, it didn't blow open, it blew off. With nothing in the tank to absorb the massive amount of heat from the burner the air inside immediately became extremely hot, and thus, as physical laws dictate, grew in volume. With a lid on and closed the volume couldn't grow so pressure increased. And very shortly the pressure grew too large and the lid of the container very literally took off towards the sky.

They never found the place where the lid landed.



Or so the story says, at least.