It has come to my attention via Google’s Webmaster Tools, that they’re reporting that malware has been found on my blog here, and are apparently going to issue site malware warnings to people about this when they click on links to this site. However it seems even Google can’t tell me where they’ve apparently found this through crawling the site:
Malware
Here is the listing from GWT, but it’s totally blank! The download all samples link also gives a totally blank CSV file. This matches my own searching through the file structure of the blog with a malware scanner, (and ClamAV to check my binary downloads), as I’ve not found anything either.
Google didn’t think it prudent to email me about this either, I only discovered these warnings this evening on checking my account; yet I get an email within 4 hours of deleting something, from the bot complaining that a page suddenly isn’t available any longer. This simply isn’t the way to do things Google, and as far as I can see these warnings have been in error, as I’ve not managed to generate an error by clicking on one of my site links in Google’s listings (from a different location, and browser, with no connection to any of my accounts, to make sure I’m not skewing the result).
Even stranger, is that my old domain name, insideelectronics.co.uk (which is still live, and redirected with a 301 to the new domain of experimental-engineering.co.uk), isn’t showing any of these site malware warnings in GWT, adding further to my suspicion that this is just Google spouting total bollocks.
However if any readers have encountered one of these apparent site malware warnings, please let me know so I can get this fixed as soon as possible. I’ve requested a review with Google to clarify things, but I don’t expect to hear back from them for at least 72 hours. Traffic doesn’t seem to have been affected so far, which probably means that none have been displayed to readers but I don’t know how long these site malware warnings have been in place.
Since the batteries on board the boat are located in the cabin, I’ve noticed something rather odd with the Carbon Monoxide detectors: when the batteries are being charged, the CO alarms are triggering on the H² that’s being released. Since the last thing we need is hydrogen building up to levels that could become explosive (which for H² is a very wide range, from 4% to 75% in standard atmospheric conditions, it also has a very low activation energy), some venting of the battery compartment is required while the batteries are being float charged. These SnO² based sensors are very cheap, so I figured I’d give one of them a go.
This particular module has a DIN rail mounting clip on the back, along with holes to mount with screws. It’s signal output is standard industrial 0-10v.
Cover Removed
Popping the cover off reveals some adjustment pots, a DC-DC converter & a single amplifier on the output. The sensor itself is plugged into a ceramic socket, so this could be replaced in the future if needed.
Output Amplifier
The output Op-Amp is an Intersil CA3140 4.5MHz BiMOS, with FET input & bipolar output stages.
Adjustment Pots
There’s a trio of potentiometers for adjusting the sensor.
Potentiometer
Function
RP2
Sensor Load Resistance Adjust
VR1
Sensitivity Adjust
VR2
Ref. Voltage Adjust
PCB Bottom
The bottom of the PCB is pretty sparse, but there’s a model number here & a website. The guys that make this seem to specialize in sensing modules.
Sensor In Cell
To give this unit a test, I removed the cell cap from one of my spare lead acids & placed the sensor head into the opening while I was giving it a topping charge. In this position any gas given off by the charging battery would instantly rise up into the sensor.
Output
Once the sensor has heated up & stabilised, the base voltage with no hydrogen present was about 1 volt. As the battery voltage rose to 13.2v the sensor began to detect some hydrogen, with the voltage rising to about 9 volts with the battery voltage at topping charge level of 14.4v.
These sensors definitely work, but there’s no calibration so it’s not possible to say how much gas is present, but this isn’t a problem for my application.
More to come when the ventilation system is installed in the battery compartment!
After I did the voltage mod on the APS-231 PSU power supply, I did some reading online & discovered there’s a more powerful PS3 supply – the APS-227. This beast has a 32A +12v rail, with a 3A +5v standby rail.
Specifications
As far as I can tell, these are used in another version of the PS3, obviously with a chunkier requirement for 12v DC.
DC Output
The main DC rail appears through the same type of connector as the smaller supply, which is compatible with standard banana plugs.
HV DC Bus Capacitors
These PSUs are very high build quality, Nichcon electrolytics are used all over the place. These are the HV DC rail filter caps, rated at 100µF 420v.
Output Synchronous FETs
Synchronous rectification is also used in these supplies, keeping the waste heat down to a minimum on the output rectification. There’s a thermistor on the heatsink to the left for the thermal protection.
+12v Rail Load Resistors
A couple of 2.2Ω resistors in series provide a minimum load to the PSU to keep things stable at low power. Adjusting the output too high will likely cause these resistors to overheat.
Transformer
The main transformer has a huge secondary winding, only 4 turns of Litz type wire, about 5mm².
Regulator Section
Here’s the point where the mod needs to be done – the same as the other PS3 supply, a single resistor needs changing for a potentiometer, it’s the 1KΩ one in the center of the photo. (White “102” text on the top, unlike the others which are yellow). Desolder this 0402 resistor.
Mod Wires
After the resistor is removed, solder the mod wires to these test points.
Mod Pot
Just like the APS-231, a 1KΩ 18-turn potentiometer is used to tweak the voltage. I’ve secured it with a drop of CA glue to the top of the standby transformer.
OVP Optocoupler Disconnected
The overvoltage protection on this supply is a little more aggressive – tripping things out at 13.4v. However it’s easy to defeat this on this particular supply, by disconnecting the “12V OVP” optocoupler from the secondary side. This does leave the supply with no active overvoltage protection, so be careful on how far the voltage gets tweaked up! The output electrolytics are rated at 16v, so there’s the potential for ballistic capacitors if things are tweaked too far!
I was recently given a Sony PS3 with a dead disc drive, and since I’m not a console gamer I figured I’d see if there were any handy parts inside. Turns out these units contain a rather nice SMPS, the Sony APS-231 with a high power 12v rail, rated at 23.5A. A bit of searching around discovered a thread on the BadCaps Forums about voltage modding these supplies for a 13.8v output, suitable for my Ham radio gear.
These supplies are controlled by a Sony CXA8038A, for which there is very little information. Active PFC is included, along with synchronous rectification which increases the efficiency of the supply, and in turn, reduces the waste heat output from the rectifiers.
Regulation Section
Like many of the SMPS units I’ve seen, the output voltage is controlled by referencing it to an adjustable shunt reference, and adjusting the set point of this reference will in turn adjust the output voltage of the supply, this is done in circuit by a single resistor.
Here’s the regulator section of the PSU, with the resistors labelled. The one we’re after changing is the 800Ω one between pins 2 & 3 of the TS2431 shunt reference. It’s a very small 0402 size resistor, located right next to the filter electrolytic for the 5v standby supply circuit. A fine tip on the soldering iron is required to get this resistor removed.
Attachment Points
Once this resistor is removed from the circuit, a 1KΩ 18-turn potentiometer is fitted in it’s place, from the Anode (Pin 3) to the Ref. (Pin 2) pins of the TS2431 shunt reference. I initally set the potentiometer to be the same 800Ω as the factory set resistor, to make sure the supply would start up at a sensible voltage before I did the adjustment.
Potentiometer
The pot is secured to the top of the standby supply transformer with a drop of CA glue to stop everything moving around. The supply can now be adjusted to a higher setpoint voltage – 13.8v is about the maxumum, as the OVP cuts the supply out at between 13.9v-14v.
Modded Voltage
After doing some testing at roughly 50% of the supply’s rated load, everything seems to be stable, and nothing is heating up more than I’d expect.
Since I’ve been working on the backend servers a lot over the past few days, I’ve decided it was time to get some broken things on the blog fixed.
Firstly, the radiation monitor graphs. Originally I was using a Raspberry Pi to grab the data from the local monitor, and that was connecting via FTP to the server over in the datacentre to push it’s graph images. Since the server is now on the same local network as the monitor, there’s no need to faff about with FTP servers, so I’ve rejigged things with some perl scripts from cristianst85 over on GitHub, running on the web server itself.
I deviated from the suggested place to put the scripts on the server & opted to store everything within the Experimental Engineering hosting space, so it gets backed up at the same time as everything else on a nightly basis.
This is also accessible from the menu at top left, the script pulls data from the monitor & updates the images every 60 seconds via a cron job.
I’ve removed a couple of dead pages from the blog system, along with some backend tidying of the filesystem. Over the years things have gotten quite messy behind the scenes. This blog is actually getting quite large on disk, I’ve hit the 15GB mark, not including the database!
Caching is enabled for all posts on the blog now, this should help speed things up for repeat visitors, but as most of my content is (large) image based, this might be of limited help. I’m currently tuning the MySQL server for the load conditions, but this takes time, as every time I change some configuration settings I have to watch how things go for a few days, before tweaking some more.
Server Control Panels – More Of The Same
Sorry Sentora. I tried, and failed to convert over to using it as my new server control panel. Unfortunately it just doesn’t give me the same level of control over my systems, so I’ll be sticking with Virtualmin for the foreseeable future. Sentora stores everything in, (to me at least), very odd places under /var/ and gave me some odd results with “www.” versions of websites – some www. hosts would work fine, others wouldn’t at all & just redirect to the Sentora login interface instead. This wasn’t consistient between hosting accounts either, and since I didn’t have much time to get the migration underway, this problem was the main nail in the coffin.
Just storing everything under the sun in /var/ makes life a bit more awkward with the base CentOS install, as it allocates very little space to / by default, (no separate /var partition in default CentOS), giving most of the disk space to /home. Virtualmin on the other hand, stores website public files & Maildirs under /home, saving /var for MySQL databases & misc stuff.
The backup system provided is also utterly useless, there’s no restore function at all, and just piles everything in the account into a single archive. By comparison, Virtualmin has a very comprehensive backup system built in, that supports total automation of the process, along with full automatic restore functionality for when it’s needed.
Sentora did have some good points though:
It handled E-Mail logins & mail filters much more gracefully than Virtualmin does, and comes with Roundcube already built into the interface ready to use. With Virtualmin the options are to use the Usermin side of the system for E-Mail, which I find utterly awful to use, or install a webmail client under one of the hosted domains (my personal choice).
Mail filtering is taken care of with Sieve under Sentora, while Procmail does the job under Virtualmin.
Sentora does have a nicer, simpler, more friendly interface, but it hides most of the low-level system stuff away, while under Virtualmin *everything* on the system is accessible, and it provides control interfaces for all the common server daemons.
This was originally going to be part of another post, but it ended up getting more complex than I originally intended so it’s been given it’s own. I go into into many of my personal security practices, on both my public facing servers & personal machines. Since the intertubes are so central to life these days, good security is a must, especially since most people use the ‘net to do very sensitive operations, such as banking, it’s becoming even more essential to have strong security.
Since bringing the new server online & exposing it to the world, it’s been discovered in record time by the scum of the internet, SSH was under constant attack within 24 hours, and within that time there were over 20,000 failed login attempts in the logs.
This isn’t much of an issue, as I’ve got a strong Fail2Ban configuration running which at the moment is keeping track of some 30 IP addresses that are constantly trying to hammer their way in. No doubt these will be replaced with another string of attacks once they realise that those IPs are being dropped. I also prevent SSH login with passwords – RSA keys only here.
MySQL is the other main target to be concerned about – this is taken care of by disabling root login remotely, and dropping all MySQL traffic at the firewall that hasn’t come from 127.0.0.1.
Keeping the SSH keys on an external device & still keeping things simple just requires some tweaking to the .bashrc file in Linux:
alias ssh='ssh -i <Path To Keys>'
This little snippet makes the ssh client look somewhere else for the keys themselves, while keeping typing to a minimum in the Terminal. This assumes the external storage with the keys always mounts to the same location.
Everything else that can’t be totally blocked from outside access (IMAP, SMTP, FTP, etc), along with Fail2Ban protection, gets very strong passwords, unique to each account, (password reuse in any situation is a big no-no) and where possible TOTP-based two factor authentication is used for front end stuff, all the SSH keys, master passwords & backup codes are themselves kept offline, on encrypted storage, except for when they’re needed. General password management is taken care of by LastPass, and while they’ve been subject to a couple of rather seriousvulnerabilities recently, these have been patched & it’s still probably one of the best options out there for a password vault.
There’s more information about those vulnerabilities on the LastPass blog here & here.
This level of security paranoia ensures that unauthorized access is made extremely difficult – an attacker would have to gain physical access to one of my mobile devices with the TOTP application, and have physical access to the storage where all the master keys are kept (along with it’s encryption key, which is safely stored in Meatware), to gain access to anything.
No security can ever be 100% perfect, there’s always going to be an attack surface somewhere, but I’ll certainly go as far as is reasonable, while not making my access a total pain, to keep that attack surface as small as possible,and therefore keeping the internet scum out of my systems.
The last layer of security is a personal VPN server, which keeps all traffic totally encrypted while it’s in transit across my ISP’s network, until it hits the end point server somewhere else in the world. Again, this isn’t perfect, as the data has to be decrypted *somewhere* along the chain.
Since Sentora is still stuck on an old version of PHP, this script will update the system to the newer v5.6, via the Remi repository, as most things are deprecating support for older PHP versions at this point. Suhosin will also be recompiled for the new PHP version.
#!/bin/bash
echo "Upgrading PHP to version 5.6. Please Wait..."
wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
sudo rpm -Uvh remi-release-7*.rpm
yum update
yum --enablerepo=remi,remi-php56 update
yum --enablerepo=remi,remi-php56 upgrade
echo "Recompiling Suhosin for PHP 5.7..."
cd /tmp
wget -nv -O suhosin.zip https://github.com/stefanesser/suhosin/archive/suhosin-0.9.37.zip
unzip -q suhosin.zip
rm -f suhosin.zip
cd suhosin-suhosin-0.9.37
phpize &> /dev/null
./configure &> /dev/null
make &> /dev/null
make install
cd ..
rm -rf suhosin-suhosin-0.9.37
echo "Restarting Web Server Services..."
systemctl restart httpd
The Remi repo will give some package authentication warnings, these can be safely dismissed during the install. I’ve tested this on a fresh install of Sentora under CentOS 7, however this process isn’t without risk! Your PHP install could be damaged!
Over the past few weeks, the host I’ve been with for over 3 years, OVH, announced a rather large price increase of 20% because of Brexit – the current universal excuse to squeeze the customer for more cash. This change has sent the price of my dedicated server solution with them to over £45 a month. Doing some napkin-calculation gave me £18 a month in extra power to run a small server locally. So I’ve decided to bring the hosting solution back to my local network & run from my domestic internet link, which at 200Mbit/s DL & 20Mbit/s UL should be plenty fast enough to handle the modest levels of traffic I usually get.
Obviously, some hardware was required for this, so I obtained this beauty cheap on eBay:
HP Proliant MicroServer Gen 8
This is a Gen 8 HP Proliant Microserver, very small & quiet, perfect for the job. This came with 4GB of RAM installed from the factory, and a Celeron G1610T running at 2.3GHz. Both are a little limited, so some upgrades will be made to the system.
Disk Bays
4 SATA drive bays are located behind the magnetically-locked front door, there’s a 250GB boot disk in here along with a pair of 500GB disks in RAID1 to handle the website files & databases. For my online file hosting site, the server has a backend NFS link direct to Volantis – my 28TB storage server. This arrangement keeps the large file storage side of things off the web server disks & on a NAS, where it should be.
Extra RAM
First thing is a RAM upgrade to the full supported capacity of 16GB. This being a Proliant server machine, doesn’t take anything of a standard flavour, it’s requirements are DDR3-10600E or DDR3-12800E (the E in here being ECC). This memory is both eye-wateringly expensive & difficult to find anywhere in stock. It’s much cheaper & easier to find the ECC Registered variety, but alas this isn’t compatible.
Over the past 48 hours or so, I’ve been migrating everything over to the new baby server, with a couple of associated teething problems, but everything seems to have gone well so far. The remaining job to get everything running as it should is an external mail relay – sending any kind of email from a dynamic IP / domestic ISP usually gets it spam binned by the big providers instantly, regardless of it actually being spam or not – more to come on that setup & configuring postfix to use an external SMTP relay server soon!
If anyone does find something weird going on with the blog, do let me know via the contact page or comments!
I’m making some changes to my hosting services, I’ve been testing Sentora, as it’s much more user friendly, if a little more limited in what it’s capable of doing, vs my go-to admin panel over the past 6+ years, Virtualmin.
I noticed that SpamAssassin isn’t set up on a Sentora server by default, so here’s a script that will get things working under a fresh Sentora install in CentOS 7:
After this script has run, some mail server settings will be changed, and the master.cf configuration file for Postfix will be backed up just in case it craps out.
Make sure the SpamAssassin daemon is running on port 783 with this command:
ss -tnlp | grep spamd
Testing is easy, send an email to an address hosted by Sentora with the following in the subject line:
If SpamAssassin is working correctly, this will be tagged with a spam score of 999.
A useful script is below, this trains SpamAssassin on the mail in the current server mailboxes. I’ve been using a version of this for a long time, this one is slightly modified to operate with Sentora’s vmail system. All mail for all domains & users will be fed into SpamAssassin in this script. I set this to run nightly in cron.
#!/bin/bash
#specify one or more users, space padded [user=(user1 user2 user3)] or empty [user=()] to include all users. All users is considered uid ≥ 1000.
user=(vmail)
#After how many days should Spam be deleted?
cleanafter=30
#backup path, comment out to disable backups
bk=/home/backup/sa-learn_bayes_`date +%F`.backup
log=/var/log/train-mail.log
#log=/dev/stdout
echo -e "\n`date +%c`" >> $log 2>&1
if [ -z ${user[@]} ]; then
echo user is empty, using all users from system
user=(`awk -F':' '$3 >= 1000 && $3 < 65534' /etc/passwd |awk -F':' '{print $1}'`)
fi
for u in ${user[@]}; do
if [ ! -d /var/sentora/vmail/*/* ]; then
echo "No such Maildir for $u" >> $log 2>&1
else
echo "Proceeding with ham and spam training on user \"$u\""
#add all messages in "junk" directory to spamassassin
echo spam >> $log 2>&1
#change this path to match your spam directory, in this case its "Junk"
#add current and new messages in Junk directory as spam
sa-learn --no-sync --spam /var/sentora/vmail/*/*/.Junk/{cur,new} >> $log 2>&1
echo ham >> $log 2>&1
#only add current mail to ham, not new. This gives user a chance to move it to spam dir.
sa-learn --no-sync --ham /var/sentora/vmail/*/*/{cur} >> $log 2>&1
fi
done
#sync the journal created above with the database
echo sync >> $log 2>&1
sa-learn --sync >> $log 2>&1
if [ $? -eq 0 ]; then
for u in ${user[@]}; do
echo "deleting spam for $u older than 30 days" >> $log 2>&1
find /var/sentora/vmail/*/*/.Junk/cur/ -type f -mtime +$cleanafter -exec rm {} \;
done
else
echo "sa-learn wasn't able to sync. Something is broken. Skipping spam cleanup"
fi
echo "Statistics:" >> $log 2>&1
sa-learn --dump magic >> $log 2>&1
echo ============================== >> $log 2>&1
if [ -n $bk ]; then
echo "backup writing to $bk" >> $log 2>&1
sa-learn --backup > $bk
fi
These large LED Philips PAR38 lamps were recently on clearance sale in my local T.N. Robinsons electrical contractors for about £3, so I decided to grab one in the hopes I might be able to hack it into a low-voltage LED lamp. These are full-size PAR38 format, with most of the bulk being the large aluminium heatsink on the front. The back section with the power supply module is secured with silicone, so some unreasonable force was required to liberate the two pieces.
Specification
These lamps are rated at 18W in operation, and are surprisingly bright for this power level.
Lens
The front has the moulded multi-lens over the LEDs, to spread the light a bit further than the bare dies.
LED Array
The LED array is two series strings of 4 LEDs, for ~24v forward voltage. Unusual for a high power LED array, this PCB isn’t aluminium cored, but 0.8mm FR4. Heat is transferred to the copper plane on the backside by the dozens of vias around the Luxeon Rebel LEDs. There is a thermal pad under the PCB for improved heat transfer to the machined surface of the heatsink.
Control PCB Top
The power supply & control PCB is pretty well made, it’s an isolated converter, so no nasty mains on the LED connections.
I posted a while back a teardown of the VM Superhub 2 router, as VM has “upgraded” to a rebranded Arris TG2492S/CE CM. Alas Virgin Media in their wisdom have decided that simple router features like being able to change the LAN subnet & DHCP server range are far too complex to trust to the Great Unwashed, so they’ve removed them entirely from the firmware, and locked the local LAN onto the 192.168.0.0/24 range.
As my network is already numbered in the 10.0.0.0/16 range, with several statically addressed devices present and other systems relying on these static assignments, using this router would have meant renumbering everything.
Luckily Virgin had the decency to leave the “modem mode” option in the firmware, effectively disabling the WiFi & routing functions & allowing the connection of a third-party router. Some searching for a suitable replacement for the core of my network turned up the Linksys WRT1900ACS. While I waited for this to arrive, some temporary workarounds were needed to make everything function well enough with VM’s crap router.
WRT1900ACS
These routers have been designed as a modern replacement for the venerable WRT54G series of routers from some time ago, with full support for OpenWRT/DD-WRT firmware, and with a beefy 1.6GHz dual core CPU & 512MB of RAM I doubt I’ll be able to knock this one over with too much network traffic! This was pretty much the most powerful router I could afford, and should mean I don’t need to upgrade for a long time. (No teardown of this yet, as it’s taking care of the network at present. Maybe some point in the future I’ll take the plunge).
The stock firmware isn’t totally awful, and has some nice features, but I decided it needed to be replaced with DD-WRT for more security & future flexibility. I’ll leave the firmware flashing stuff for another post 😉
This is a little bit of kit I got to talk to the Webasto TT-V I salvaged from a scrap Jaguar S-Type, and converts USB-RS232 to the standard car diagnostic ODB connector. (These are a much cheaper option at £4 than the official Webasto diagnostic adaptor & loom which is over £90.
PCB Top
There’s really not much to this adaptor, the only signals that are routed to the ODB connector seem to be the +12v on pin 16, K-Line on Pin 7 & L-Line on pin 15. The main IC here is a CH340 USB-Serial interface, with some glue logic in the form of an LM339 quad comparator.
PCB Reverse
The reverse side of the PCB only has the power indicator LED.
As I mentioned in the previous post, these heaters have a standard interface that’s used for control & diagnostics, the W-Bus. This is transmitted over the K-Line of the vehicle bus, and all heaters, regardless of firmware modifications done by the various car manufacturers respond to this interface. Official Webasto diagnostic adaptors are available, but these are just a very expensive serial adaptor. A much cheaper option is a ~£5 Universal ODB adaptor.
ODB2
Above shows the signals on the ODB connector – the ones we’re interested in here are Pin 16, the +12v supply, and Pin 7, K-Line. Connect Pin 16 to the positive supply to the heater, and Pin 7 to Pin 2 on the Webasto heater. (Valid for all TT-V heaters).
Device Selection
Once these two connections are made to the heater, fire up the Thermo Test software. The screen above will be displayed. Pick W-Bus at top left.
COM Port Selection
First thing, connect the ODB adaptor to USB, and change to the correct COM port in Thermo Test. There may be several in the list, but a newly connected USB device should show up with the highest COM number.
Thermo Test
Once Thermo Test is running, start communications by going to the Diagnosis Menu > Start Diagnostic (F2 keyboard shortcut).
Initialized
After a few seconds, communication will be established. This will show faults, if any are present, and allow testing of the heater & it’s component parts. A summary report can be generated with Diagnosis > View Summary:
Diagnosis report Webasto Thermosystems
------------------------------------------------------------------------------------------
Configuration:
--------------
W-Bus version...............................................................3.3
Device name.............................................................X204 SH
W-Bus code.......................................................715CC0E73F8000
Fuel type................................................................Diesel
Circulating pump in control idle period.......................................0
Heating duration limitation.................................................255 [min]
Factor for shortening of ventilation duration...............................1/1
Device identification number..........................................09007236E
Dataset identification number.......................................09006806H05
Software identification number........................................000000000
HW version................................................................51/03
SW version..................................................Tuesday/07/04 12.12
SW version (EEPROM).........................................Tuesday/07/04 12.12
Date of manufacture control unit.......................................27.10.03
Date of manufacture heater.............................................04.02.04
Customer identification number.....................................4R8318K463AE
Serial number........................................................0000123626
Test signature.............................................................4B42
Minimum voltage threshold....................................................10 [V]
Maximum voltage threshold....................................................16 [V]
Delay for supply voltage min. detection......................................20 [s]
Delay for supply voltage max. detection.......................................6 [s]
Operating data:
---------------
Working hours.............................................................44:03 [h:m]
Operating hours.........................................................5388:08 [h:m]
Start count...............................................................19129
Burning duration PH 1..33%.................................................0:00 [h:m]
Burning duration PH 34..66%................................................0:00 [h:m]
Burning duration PH 67..100%...............................................0:00 [h:m]
Burning duration PH >100%..................................................0:00 [h:m]
Burning duration SH 1..33%.................................................0:00 [h:m]
Burning duration SH 34..66%................................................0:00 [h:m]
Burning duration SH 67..100%...............................................0:00 [h:m]
Burning duration SH >100%..................................................0:00 [h:m]
Working duration PH........................................................0:51 [h:m]
Working duration SH......................................................121:10 [h:m]
Start counter PH..............................................................6
Start counter SH............................................................854
Ventilation duration.......................................................0:00 [h:m]
Error:
------
------------------------------------------------------------------------------------------
12.03.17 17:17:30 Webasto Thermo Test 2.16.1
This shows all the important stuff, including running hours. (5388Hrs on this heater!). Most importantly, there are no faults listed.
Heater Running
The heater can be fully tested by issuing a start command from the Command Menu > Parking Heating option. Obviously cooling water will be required for this, along with an external water pump. (The water pump control output on these heaters seems to be totally disabled in firmware, as they rely on the engine’s coolant pump). I used a bucket of water along with a small centrifugal pump to provide the cooling. During this test I noted that the firmware is much more aggressive in these units. The marine versions shut down at ~72°C water temperature, whereas these don’t so the same until ~90°C.
Now I’ve managed to communicate with the heater, I’ll get onto building a standalone controller so I can dispense with the Windows VM for control.
This is another automotive part, this one was found lurking inside an LCD info display from a BMW. I didn’t manage to find a datasheet for this one, the neither the part number on the package or the wafer code on the die itself revealed anything.
Here’s another Diesel-fired heater related project – these Webasto heaters are fitted to Jaguar S-Type cars as auxiliary heaters, since (according to the Jag manual), the modern fuel-efficient diesels produce so little waste heat that extra help is required to run the car’s climate control system. (Although this seems to nullify any fuel efficiency boost, as the fuel saved by not producing so much waste heat in the engine itself is burned in an aux heater to provide heat anyway). The unfortunate part is these units don’t respond to applying +12v to Pin 1 of the ECU to get them to start – they are programmed to respond to CAN Bus & K-Line Bus only, so they require a bit more effort to get going. They also don’t have a built-in water circulation pump unlike the Webasto Thermo Top C heaters – they expect the water flow to be taken care of by the engine’s coolant pump.
Webasto LabelWater Side
The water ports are on the side of this heater instead of the end, the heat exhanger is on the left. These hearers are fitted to the car under the left front wing, behind a splash guard. Pretty easy to get to but they get exposed to all the road dirt, water & salt so corrosion is a little problem. The fuel dosing pump is in a much more difficult spot to get at – it’s under the car next to the fuel tank on the right hand side. Access to the underside with stands is required to get at this.
ECU Side
The ECU side has all the other connections – Combustion air, exhaust, fuel, power & control.
External Connectors
Only two of the external connectors are used on these heaters, the large two pin one is for main power – heavy cable required here as the current draw can climb to ~30A on startup while the glow plug fires. The 8-pin connector on the left is the control connector, where the CAN / K-Line / W-Bus buses live. The fuel dosing pump is also supplied from a pin on this connector. The small 3-pin under that is a blank for a circulation pump where fitted. Pinouts are here:
Pin
Signal
1
Battery Positive
2
Battery Negative
Pin Number
Signal
Notes
1
Telestart / Heater Enable
Would usually start the heater with a simple +12v ON signal, but is disabled in these heaters.
2
W-Bus / K-Line
Diagnostic Serial Bus Or Webasto Type 1533 Programmer / Clock
3
External Temp Sensor
4
CAN-
CAN Bus Low
5
Fuel Dosing Pump
Fuel Pump output. Connect pump to this pin & ground. Polarity unimportant.
6
Solenoid Valve
Fuel cutoff solenoid optionally fitted here.
7
CAN+
CAN Bus High
8
Cabin Heater Fan Control
This output switches on when heater reaches +50°C to control car heater blower
Pin
Signal
Notes
1
?
?
2
Circulation Pump +
3
Circulation Pump -
ECU Cover Removed
Removing the clipped-on plastic cover reveals the other ECU connectors. The large white one feeds the glow plug, & the large multi-pin below brings in the temp & overheat sensor signals.
MC9S12DT128B Microcontroller
The heart of the ECU is a massive microcontroller, a Freescale MC9S12DT128B, attached to a daughterboard hooked into the ECU power board.
Power Section
The high power section is on the board just under the connectors, here all the large semiconductors live for switching the fan motor, glow plug, external loads, etc.
LIN & CAN Bus Transceivers
The bus transceivers are separate ICs on the control board, a TJA1041 takes care of the CAN bus. There’s also a TJA1020 LIN bus transceiver here, which is confusing since none of the Webasto documentation mentions LIN bus control.
Combustion Fan Motor
The combustion fan motor is in the ECU compartment, nicely sealed away from the elements. There is no speed sensor on these blowers, unlike the Eberspacher ones.
Motor Details
The motor is a Buhler, rated at 10.5v.
Water Ports & Combustion Fan Cover
Unclipping the cover from the other end reveals the combustion fan, it’s under the black cover. (These are side-channel blowers, to provide the relatively high static pressure required to run the burner).
Sensor Clip
The overheat & temperature sensors are on the end of the heat exchanger, retained by a stainless clip.
Temp & Overheat Sensors
With the clip removed, the sensors can be seen better. There’s some pretty bad corrosion of the aluminium alloy on the end sensor, it’s seized in place.
Burner
The heater splits in half to reveal the evaporative burner itself. I’ve already cleaned the black crud off with a wire brush here, doesn’t look like this heater has seen much use as it’s pretty clean inside.
Burner Chamber
Inside the burner the fuel evaporates & is ignited. There is a brass mesh behind the backplate of the burner to assist with vaporisation.
Glow Plug
The glow plug is fitted into the side of the burner ceramic here. This is probably a Silicon Carbide device. It also acts as a flame sensor when the heater has fired up. The fuel inlet line is to the left under the clamp.
Heat Exhanger
The hot gases from the burner flow into the heat exchanger here, with many fins to increase the surface area. There’s only a couple of mm coating of carbon here, after 10 years on the car I would have expected it to be much more clogged.
I’m currently waiting on some components to build an interface so I can get the Webasto Thermo Test software to talk to the heater. Once this is done I can see if there are any faults logged that need sorting before I can get this heater running, but from the current state it seems to be pretty good visually. More to come once parts arrive!
The full service manual for these heaters can be grabbed from here, along with the wiring details for the Jaguar implementation & the Thermo Test software for talking to them:
This is a chip aimed at the automotive market – this is a low power voltage regulator for supplying power to microcontrollers, for instance in a CD player.
TDA3606 Die
The TDA3606 is a voltage regulator intended to supply a microprocessor (e.g. in car radio applications). Because of low voltage operation of the application, a low-voltage drop regulator is used in the TDA3606. This regulator will switch on when the supply voltage exceeds 7.5 V for the first time and will switch off again when the output voltage of the regulator drops below 2.4 V. When the regulator is switched on, the RES1 and RES2 outputs (RES2 can only be HIGH when RES1 is HIGH) will go HIGH after a fixed delay time (fixed by an external delay capacitor) to generate a reset to the microprocessor. RES1 will go HIGH by an internal pull-up resistor of 4.7 kΩ, and is used to initialize the microprocessor. RES2 is used to indicate that the regulator output voltage is within its voltage range. This start-up feature is built-in to secure a smooth start-up of the microprocessor at first connection, without uncontrolled switching of the regulator during the start-up sequence. All output pins are fully protected. The regulator is protected against load dump and short-circuit (foldback
current protection). Interfacing with the microprocessor can be accomplished by means of a battery Schmitt-trigger and output buffer (simple full/semi on/off logic applications). The battery output will go HIGH when the battery input voltage exceeds the HIGH threshold level.
Time for another teardown! Here’s a pocket-sized headphone amplifier for use with mobile devices. This unit is powered by a built-in lithium cell, and can give some pretty impressive volume levels given it’s small size.
Audio Connections
The 3.5mm audio input & output jacks are on the front of the unit, along with the relatively enormous volume knob & power switch. There’s a little blue LED under the switch that lets the user know when the power is on, but this is a very sedate LED, using very little power.
Gain & Charging
On the back is the High-Low gain switch, and the µUSB charging port. There’s another indicator LED to show that the internal cell is charging, in this case a red one.
PCB Top
Removing a couple of cap screws allows the internals to slide out of the extruded aluminium casing. Most of the internal space is taken up by the 1Ah lithium cell, here on the top of the PCB secured by some double-sided tape. The volume potentiometer is mounted on a small daughterboard at right angles to get it to fit into the small vertical space in the case.
PCB Rear
The bottom of the PCB is equally as sparse – the only ICs being the main audio amp in the centre & the battery charger IC at the top.
Amplifier IC
The main audio amplifier is a TP9260, I couldn’t find a datasheet on this, so I’m unsure of what the specs are. The row of resistors above the IC are for the gain divider circuit. There’s also a pogo pin on the right that makes contact with the back panel of the case for grounding.
Battery Charger
Battery charging is taken care of by a UN8HX 500mA linear charging IC, not much special here.
This little amplifier seems to be pretty well made, considering the price point. The only issue I’ve had so far is the audio cables act like antennas, and when in close proximity to a phone some signal gets picked up & blasted into the headphones as interference.
Here’s a jellybean chip – a DC motor driver. This device has all the logic to drive a small motor, such as that used to drive the tray of a CD drive in both directions. The control logic is at the bottom of the die, while the main power transistors are at the top, in H-Bridge formation.
Here’s a very common chip used in older LCD monitors. This converts the incoming VGA signal into LVDS for the panel itself.
gmZAN3 Die
The gmZAN3 is a graphics processing IC for Liquid Crystal Display (LCD) monitors at XGA resolution. It provides all key IC functions required for the highest quality LCD monitors. On-chip functions include
a high-speed triple-ADC and PLL, a high quality zoom and shrink scaling engine, an on-screen display (OSD) controller and digital color controls.
It’s been 4 months since I did a rejig of my storage server, installing a new 16-port SATA HBA to support the disk drives. I mentioned the factory fan the card came with in my previous post, and I didn’t have many hopes of it surviving long.
Heatsink
The heatsink card has barely had enough time to accumulate any grime from the air & the fan has already failed!
There’s no temperature sensing or fan speed sensing on this card, so a failure here could go unnoticed, and under load without a fan the heatsink becomes hot enough to cause burns. (There are a total of 5 large ICs underneath it). This would probably cause the HBA to overheat & fail rather quickly, especially when under a high I/O load, with no warning. In my case, the bearings in the fan failed, so the familiar noise of a knackered sleeve bearing fan alerted me to problems.
Replacement Fan
A replacement 80mm Delta fan has been attached to the heatsink in place of the dead fan, and this is plugged into a motherboard fan header, allowing sensing of the fan speed. The much greater airflow over the heatsink has dramatically reduced running temperatures. The original fan probably had it’s bearings cooked by the heat from the card as it’s airflow capability was minimal.
Fan Rear
Here’s the old fan removed from the heatsink. The back label, usally the place where I’d expect to find some specifications has nothing but a red circle. This really is the cheapest crap that the manufacturer could have fitted, and considering this HBA isn’t exactly cheap, I’d expect better.
Bearings
Peeling off the back label reveals the back of the bearing housing, with the plastic retaining clip. There’s some sign of heat damage here, the oil has turned into gum, all the lighter fractions having evaporated off.
Rotor
The shaft doesn’t show any significant damage, but since the phosphor bronze bearing is softer, there is some dirt in here which is probably a mix of degraded oil & bearing material.
Stator & Bearing
There’s more gunge around the other end of the bearing & it’s been worn enough that side play can be felt with the shaft. In ~3000 hours running this fan is totally useless.
I recently got the latest upgrade from Virgin Media, 200Mbit DL / 20Mbit UL, and to get this I was informed I’d have to buy their latest hardware, since my existing CPE wouldn’t be able to handle the extra 5Mbit/s upload speed. (My bullshit detector went off pretty hard at that point, as the SuperHub 2 hardware is definitely capable of working fine with 20Mbit/s upload rates). Instead of having to return the old router, I was asked to simply recycle it, so of course the recycling gets done in my pretty unique way!
Mainboard
The casing of these units is held together by a single screw & a metric fuckton of plastic clips, disassembly is somewhat hindered by the radio antennas being positioned all over both sides of the casing. Once the side is off, the mainboard is visible. The DOCSIS frontend is lower left, centre is the Intel PUMA 5 Cable Modem SoC with it’s RAM just to the lower right. The right side of the board is taken up by both of the WiFi radio frontends, the 5GHz band being covered by a Mini PCIe card.
Atheros Gigabit Switch
The 4 gigabit Ethernet ports on the back are serviced by an Atheros AR8327 Managed Layer 3 switch IC, which seems to be a pretty powerful device:
The AR8327 is the latest in high performance small network switching. It is ultra low power, has extensive routing and data management functions and includes hardware NAT functionality (AR8327N). The AR8327/AR8327N is a highly integrated seven-port Gigabit Ethernet switch with a fully non-blocking switch fabric, a high-performance lookup unit supporting 2048 MAC addresses, and a four-traffic class Quality of Service (QoS) engine. The AR8327 has the flexibility to support various networking applications. The AR8327/AR8327N is designed for cost-sensitive switch applications in wireless AP routers, home gateways, and xDSL/cable modem platforms.
Unfortunately most of the features of this router are locked out by VM’s extremely restrictive firmware. With any of their devices, sticking the VM supplied unit into modem mode & using a proper router after is definitely advised!
Intel Puma 5 CM CPU
The cable modem side of things is taken care of by the Intel PUMA 5 DNCE2530GU SoC. This appears to communicate with the rest of the system via the Ethernet switch & PCI Express for the 5GHz radio.
Atheros WiFi SoC
The 2.4GHz radio functionality is supplied by an Atheros AR9344 SoC, it’s RAM is to the left. This is probably handling all the router functions of this unit, but I can’t be certain.
Atheros LAN PHY
A separate Ethernet PHY is located between the SoC & the switch IC.
5GHz Radio Card
The 5GHz band is served by a totally separate radio module, in Mini PCIe format, although it’s a bit wider than standard. This module will probably be kept for reuse in another application.
Power Supplies
All down the edge of the board are the multiple DC-DC converters to generate the required voltage rails.
MaxLinear MXL261 Frontend
The DOCSIS frontend is handled by a MaxLinar MXL261 Tuner/Demodulator. More on this IC in my decapping post 🙂
The Unknown One
I’ve honestly no idea what on earth this Maxim component is doing. It’s clearly connected via an impedance matched pair, and that track above the IC looks like an antenna, but nothing I search for brings up a workable part number.
2.4GHz Frontend
The RF switching & TX amplifiers are under a shield, these PA chips are SiGe parts.
Atheros 5GHz Radio
Pretty much the same for the 5GHz radio, but with 3 radio channels.
Time for more silicon pr0n! When Virgin Media supplied me with a new modem, they requested I “recycle” the old one, so naturally it got gutted for the component parts. This particular IC is the frontend of the RF tuner. Unfortunately no datasheet is available, but I did manage to find some info in a press release. The sections are clearly identifiable, the RF section is on the left, while the rest of the demodulating logic is hidden on the right under a metal layer.
MXL261 Die – Click to Embiggen!
The MxL261 is based on MaxLinear’s low-power, digital CMOS process RF and mixed-signal technology. It is a single-die, global standards, digital cable front end with integrated splitter, two 100MHz wideband tuners, four QAM demodulators and a four-channel-wide IF output.
Here’s a piece of tech that is growing all the more important in recent times, with devices with huge battery capacities, a quick charger. This unit supports Qualcomm’s Quick Charge 3 standard, where the device being charged can negotiate with the charger for a higher-power link, by increasing the bus voltage past the usual 5v.
Rear
The casing feels rather nice on this unit, sturdy & well designed. All the legends on the case are laser marked, apart from the front side logo which is part of the injection moulding.
Specifications
The power capacity of this charger is pretty impressive, with outputs for QC3 from 3.6-6.5v at 3A, up to 12v 1.5A. Standard USB charging is limited at 4.8A for the other 3 ports.
Ports
The two of the 5 USB ports are colour coded blue on the QC3 ports. The other 3 are standard 5v ports, the only thing that doesn’t make sense in the ratings is the overall current rating of the 5v supply (4.8A), and the rated current of each of the ports (2.4A) – this is 7.2A total rather than 4.8A.
Top Removed
The casing is glued together at the seam, but it gave in to some percussive attack with a screwdriver handle. The inside of this supply is mostly hidden by the large heatspreader on the top.
Main PCB Bottom
This is a nicely designed board, the creepage distances are at least 8mm between the primary & secondary sides, the bottom also has a conformal coating, with extra silicone around the primary-side switching transistor pins, presumably to decrease the chances of the board flashing over between the close pins.
On the lower 3 USB ports can be seen the 3 SOT-23 USB charge control ICs. These are probably similar to the Texas Instruments TPS2514 controllers, which I’ve experimented with before, however I can’t read the numbers due to the conformal coating. The other semiconductors on this side of the board are part of the voltage feedback circuits for the SMPS. The 5v supply optocoupler is in the centre bottom of the board.
Heatsink Removed
Desoldering the pair of primary side transistors allowed me to easily remove the heatspreader from the supply. There’s thermal pads & grease over everything to get rid of the heat. Here can be seen there are two transformers, forming completely separate supplies for the standard USB side of things & the QC3 side. Measuring the voltages on the main filter capacitors showed me the difference – the QC3 supply is held at 14.2v, and is managed through other circuits further on in the power chain. There’s plenty of mains filtering on the input, as well as common-mode chokes on the DC outputs before they reach the USB ports.
Quick Charge 3 DC-DC Converters
Here’s where the QC3 magic happens, a small DC-DC buck converter for each of the two ports. The data lines are also connected to these modules, so all the control logic is located on these too. The TO-220 device to the left is the main rectifier.
Another decapped IC! This one is an ST L6219 750mA stepper motor driver. The control logic is all at the bottom of the die, with the high current H-Bridge transistors at the top.
Here’s another die photo from the collection, this time it’s a 512-step digital pot from Analog devices.
AD8403 Die
Tip Jar
If you’ve found my content useful, please consider leaving a donation by clicking the Tip Jar below!
All collected funds go towards new content & the costs of keeping the server online.
