I was thinking about another Arduino Christmas post. I'd got a string of 50 WS2801 LEDs left over from another project, so I thought I'd write some code to display some pretty patterns. As it turns out the FASTLEDS library had just what I needed in the examples section, so I uploaded that to a nano, and hooked up the GND. CLK and data lines to the nano, and was enjoying the lightshow.
I needed to power the LEDs from a bigger supply than can be supplied by the nano itself, as the LEDs draw a shade over 1 amp when flat out, so I got out a little 5V 5A bench supply I bought from a car-boot sale in days gone by. When I saw it at the bootsale, I didn't know what it was, but for the price, there was a nice case, a panel meter and, somewhat unusually, a keyswitch.
It's a useful little thing, but doesn't get used that often. Great for when the main workshop supply just isn't quite big enough for the job.
All was well. I left it running for a bit, and went to watch some TV... I thought I heard a pop from the workshop. I glanced over, and could see the LEDs happily flashing away.... then about a minute later , that smell of burning molasses. Ugh... somewhere there's a Rfia let go!
Sure enough, the smell was coming from the supply. I switched it off and opened the window, and closed the workshop door behind it.
Once the air had cleared, I disassembled the unit to find a Gould MMG-5 power supply module inside. It's all very nicely made.
It proved a little challenging to get open, this plastic rivet must be removed ...
... this cover removed ...
... this flexible solder tag unsoldered ...
... and that recessed nut undone ...
The electronics can then be removed.
There's a nice date on the transistor , 44th week of 1977.
Switch mode supplies were starting to get commonplace in television sets around this time, so the technology wasn't exactly new...
... although, this small daughter board seems to have optical isolators, which TV's of the time certainly didn't have. There's no bespoke switched mode controller IC here. It's made up from a logic IC and a slack handful of opamps.
And there's the guilty party. Sure enough a Rifa! It's replaced with a brand new X2 Class Epcos branded part of the same value.
And another saved from landfill...
Incidentally, the meter has a shunt to read 0-10A, despite the supply only being capable of 5!
Remember the Strathclyde STD 305D I built a supply for here? Well, it ran for a while then the display started to play up ....
It stopped indicating the correct speed. Ugh.
I got it back into the workshop, and poked around the board.
The vacuum fluorescent display is driven by a long obsolete counter, a Plessey ZN1040. The good news is, it's actually counting. The bad news is that's all it does. The way it indicates RPM is it counts some pulses derived from the motor's tachometer , and a reset pulse comes along and resets the count. The display is then updated on reset, so 33 pulses per "reset" indicates 33 RPM on the display ... A prod round with the 'scope shows the reset pulse is missing. The pulse is generated from a Plessey ZN1034 precision timer IC, again long since obsolete. Damn.
It's a bit like a posh 555 IC.. It's simply configured as a bistable. Replacements appear to be available on eBay, but are of questionable parentage. (You can't tell me that when this thing went obsolete in the early 80's, China had massive stocks of them).
We need to find another solution.
This is a quick sketch of the relevant bit of the STD305D's schematic.
As shown here, it's the Q output that feeds the reset pin of the counter. The complimentary output (not Q) of the ZN1035 timer is also feeding something, so we'll need to implement that also ..
The power supply available is 5V, so that's easy. How about an ATTINY85 ? Perfect. Two pins connected for both outputs, Q and not Q. Should be easy enough, and be easy to fit. Good, a plan.
The program is simple enough ...
#include <avr/io.h>
int timing = 1000;
void setup() {
// PB 3 and 4 to output
DDRB |= (1 << PB3);
DDRB |= (1 << PB4);
}
void loop()
{
//set PB3 , unset PB4
PORTB = 0b001000;
delay (timing);
// set PB4, unset PB3
PORTB = 0b010000;
delay (timing);
}
I've used direct port manipulation to minimise the overlap between Q and not Q. digitalWrite takes longer to change the state of the port. I don't know whether that would be an issue in this application, but it's best practice. We can tweak the timing variable to suit.
The ATTINY85 is loaded into an adaptor and programmed using my ISP programmer.
As power consumption isn't an issue, the micro is set to run at 16MHZ internal clock.
The ATTINY85 is pressed into service, and produces odd results. The reset line still isn't resetting the ZN1040 counter. Checking through, I connect it directly to the reset line of the ZN1040 ... not a good idea, as this instantly kills the output pin on the TINY. :(
Liberating the ZN1040 pin from the board, the pin on the IC measures a few ohms to ground. Not only is our ZN1034 dead, but so is the ZN1040.... What's common here? Ugh , the +5V rail.
I measure the 5V rail ... it's 5.1V , close enough.... hang on 5.2 .... 5.3 ... it ends up at 6V , the regulator on the power supply board is shot. It's a simple enough Zener diode and transistor affair... I sack it off, remove the BD239 pass transistor, and fit a 7805 on a heatsink. It's all a bit too late for our poor ZN1034 and 1040 though.
So what to do? Obviously remove both IC's. Feed the pulses from the tacho into an arduino, calculate the speed, and output it over the existing discreet transistor drive circuitry to the display. Works for me.
Studying the datasheet for the ZN1040 , gives us all the info we need...
OK, so this is shown for LED displays, but the principle will be identical. Four lines switch on the supply to select which digit MSD (Most significant) to LSD (Least significant), only three are connected in our application ... We'll need to multiplex these, and the actual segment drives (A-G) need to be pulled low to illuminate the display.
First up, is go get our arduino to read the pulses from the tacho.
They should be arriving at pin 22...
... and, sure enough there's a nice negative going pulse train arriving, and it varies with the speed control. Great.
We'll drop these pulses into INT0 on our arduino, and trigger an interrupt on a falling edge.
A quick piece of code is conjured up to read RPM and output over the serial interface. It's uncalibrated at present, but is near enough , reading 33, 45 and 78 RPMish...
Excellent, we can return to calibration later (the turntable is currently upside down with no platter on it).
Now to deal with driving the existing display. The ZN7040 is capable of muliplexing a 4 digit display. In this application only three digits are used. A quick bit of reverse engineering shows those digits are the 3 most significant digits. These are coupled to our arduino on pins A1- A3 and set to digital outputs. Each of these pins feeds a grid, and taking this high allows the display to function.
Arduino pins 3 to 9 are connected to the segments drives for A through to G. These are used to individually control each segment's anode. Pulling the pin low, switches on the anode, and illuminates the segment.
Bingo, a muliplexed display. Now to couple the two parts together...
And finally to reassemble and calibrate ...
Nice!
I will NOT be beaten by mere machinery!!
The software is available as usual from my github.
And another saved from landfill, these really are a stunning deck.
In an upcoming project (that is, as usual, taking far too long) requires some indication of audio input level.
So the plan is to have a meter, only this time drive it using an arduino PWM output. Seems like a good plan, as I already use said Arduino to perform one task on start-up, and it's sat there doing nothing most of the time.
So here's the simple input stage. It's job is to take our audio, and amplifying it, so it swings the whole range of our 5V rail, using a rail-to-rail opamp, and centering it on 2.5V, so it doesn't go negative. This is then fed into A0 of our arduino.
Now I need a peak value of our audio, so the usual trick is to rectify it. Rather than implementing this as , say a precision full wave rectifier, I thought I'd have a go in software.
Now the software reads the ADC, and if the result is greater than 512, the result stands and has 512 subrtracted from it. If the result is 511 or less, it's inverted and the result stands, IE is the ADC returns 0, it's inverted to 511, if it's 511, it's inverted to 0. That way, if our peaks are positive or negative, we're measuring a peak. It's a software rectifier.
And that's about all we care about. the output is divided by two and sent as a PWM to the meter. There's a bit in the software to decay the pointer.
At first glance, it appears to work well, given the limitations of the ATMEGA328's A/D ... but it's frequency response is awful...
The problem is with aliasing. Mr Nyquist tells us that we need to sample at least twice as fast as our highest frequency. The software may be going as fast as it can (albeit I haven't employed any techniques to optimise it) , but it's frequency response is poor, and unpredictable (or is it?)
Here's a quick video to show the issue...
So it is predictable, and poor. Because we are sampling at a constant rate, at anything but that frequency, we will not be sampling the same point of our sinewave, let alone the peak, we could be sampling on the slope, or even at the central crossing point, and giving false readings. We can also see the frequency response improving at the higher frequencies. This is called "spectral folding" , and you can learn more about it here.
So there it is ... it might be OK to give a sort of visual response to some music, but it's woefully inadequate for my purposes. I could use a faster micro (and a better A/D), but that's overkill for this project. I've going back to doing this in good old fashioned analogue!
"This belongs to my mate, he says it's crackling, can you have a look?"
Yeah ... why not?
It's a Rockit monitor.
Sure enough it's popping and crackling ... off with those 8 screws on the edge of the back panel, and carefully remove...
Usual idea, amplifiers (in this case two, one for the tweeter, one for the sub) and transformer/ active cross over all built onto the back panel...
The fault is immediately obvious... the dreaded black goo ... This is some sort of adhesive applied liberally to the pcb to stop the capacitors and other large components "falling out" because they don't trust their soldering (this is a somewhat sarcastic guess, but I fail to see any real reason for it!) It has an issue. After a time, if it's got hot, it can start to conduct, causing undesired operation of the device. I see it quite often.. for example here.
I can see it's got very dry and crusty (and most likely conductive) in a couple of places. Most noticably here ... we'll have to clean it all off to make a reliable repair. The dry stuff mostly chips off....
The rest needs a soak in a bit of acetone (or nail varnish remover), I add a bit to bits of kitchen roll, and allow it to soak in for 30 mins, and the goo just wipes off...
Get as much off as possible.
... and reassemble. Simple fix.
I warned Mike the other one would need doing as well, and cleaned that one up too...
Well, the latest in the line of Raspberry Pi's is here, the Pi 400 ... Lord knows why people seem to like unboxing videos ... is it a kind of bragging?
No idea. The kids seem to like it , so here's some pictures...
Oh look a box from Farnell...
It's got some packing in it ... the excitement...
... the product box...
... behold the Pi400...
... the official power supply, and official mouse ... I can hardly contain myself (if you have detected a shade of sarcasm, you're correct)
Our lovely marketing lady, Jilly.. "Where's the rest of it?"
And LP showing the rear panel.
Plugged in and booted..
Official mouse ...
.. set up and updated...
So that's the silly unboxing rubbish dealt with. I would have made a video, except I couldn't be bothered, just close your eyes and picture it, with some ghastly music playing over the top.
Now to the real stuff...
What do you really get for your £90?
It's a Pi4 with 4GB of ram, only rather than running at 1.5GHz, the same ARM v8 Cortex-A72 is running a bit faster at 1.8GHz, all packaged inside a chiclet keyboard, a 16GB memory card, loaded with the Raspberry OS, a 3A power supply and the offcial mouse.
A review... It performs just like a Pi4, so really that's just fine. The chiclet keyboard works nicely. The offical mouse is ,well, barely adequate, it works, but ergonomics had passed this one by.
You get one less USB than on a Pi4, and the GPIO port is available on the rear.
Why would you want one?
I actually bought this for two reasons. One is it's easier to set up projects (destined for a Pi4) on this, as it's compact, and avoids having (yet) even more wires and keyboards hanging about in the workshop.. similar reasons I have an arduino uno board for developing projects that will eventually exist on a stand alone ATMEGA328.
The second is to run the excellent HAMPI radio ham image by Dave Slotter W3DJS. This should give me a flexible, small, quiet, low power platform to run some ham radio experiments on.
Oh, and yes, there's a third reason. It reminds me of the computers I had in the 80's .. the Oric-1 , C64 and Spectrum. It gives me a nice warm feeling.
On old school pal, a once estate agent and daytime telly presenter, now a famous comedian (so we'll let him off for the first couple of misdemeanors) dropped me a message on Facebook....
"I've followed some of your repairs with astonishment and very little understanding.
Do you think you could look at something for me?"
Yeah .. why not ..
It's a diversity amplifier from a BMW E61 Tourer.
They're apparently a really common fault on the E61 tourer, as they're situated in the tailgate, and suffer with water ingress, and Nick confirms this one was full of water when removed, and he'd left it to dry out on a radiator for a few days...
I expect it to be full of corrosion ...
The plastic case just unclips, and reveals the PCB.
Which is surprisingly clean and lacking in corrosion...
So. The plan is to first work out what on earth this thing is supposed to be doing. The faults are the remote locking wasn't working, and the radio would reset to Radio 2 with the bass and treble set to maximum whenever the ignition key was removed... hmmm.
So, a spot of reverse engineering is required.
The antennas (there are two) seem to feed into the red and black sockets on the top edge of the PCB. I suspect these may well be "hidden" antennas in the glass... The signal is filtered and is sent to a TEA6101 diversity switch. This analyses the signal from each antenna, and sends the strongest one on to the receivers. One signal is sent to a conventional TDA1576 FM demodulator, and on out to an amplifier and off-board via the molded socket.
The second half goes to a TDA5210 UHF receiver/decoder.. what's the betting that's our remote lock/unlock ? Output from that feeds the IC under the heatsink clamp...
There's also a small switching supply for +5V, and some amplification and filtering of RF along the way.
Working out where the +12V power goes to the board, brings up the +5V supply... good. Poking round the data lines with an oscilloscope shows no activity ... but is it expecting data from the car?
A careful visual inspection of the board under the microscope shows no corrosion. Time to remove the heatsink clamp...
I thought this may be hiding some sort of power amplifier, but no, it's a microcontroller. There's also some corrosion around it's 6MHz ceramic oscillator.... Scoping up around the microcontroller shows no activity ...
Removing the oscillator shows up the corrosion.. See that black line between the two of those long pads?
It's duly cleaned up ...
The oscillator put back into place after checking the bottom of it is clean.... It's soldered back in with the hot air tool.
When I removed the oscillator, I also removed a small decoupling capacitor by accident (there can be some collateral damage with a hot air tool!) ... thankfully I didn't lose it, and this is hand soldered back in place.
I don't think the heatsink clamp is actually anything of the sort. I think it's an RF shield. Anyway it's replaced. Powering up now shows some activity on several of the microcontroller's pins..
So, it's time to reassemble it, and send it back to Nick to see if it works or not ... fingers crossed.
I've been a spectacle wearer for 35 years, and almost every pair I've ever owned has had the same issue... an issue I'm sure many of you can relate to.
There you are, going about your business, then, with no warning ... *thunk*
One of your lenses falls out ...
You pick the lens up, only to find the microscopic screw that held it in has, of course, vanished (or at least, due to your now compromised vision, you can't find it)
Now, I appreciate the need for a fixing to hold the things together. I also appreciate said screw is under a lot of stress, the glasses twisting as you take them on and off, the heating and cooling that goes on etc, so that poor little screw works loose. I get that...
So why in god's name put the screw in from the bottom? Just WHY?
It comes loose, falls out, followed a few seconds later by the lens...
Why not put it in from the top? It may work loose, but at least it's got less chance of falling out?
Also, have you people never heard of locktight? Boeing have been gluing aeroplane wings on for years... can you not find a suitable adhesive?
It's not like these things are cheap to buy (aeroplanes or glasses)....
So, if you're a glasses wearer, or you partner is, take a moment today to check your screws. Stick a bit of nail varnish on the threads. You're welcome...
... this flexible solder tag unsoldered ...
