Search This Blog

Sunday, December 9, 2018

Adding metalurgical capability to a biological microscope - part 1

Biological microscopes among a few other things, are characterized by the fact that rely on transmitted light rather than reflected light, to produce an image of the specimen.This is adequate for most biological needs because the specimen can either be made thin enough for light to go through, or the medium and/or the specimen itself is relatively transparent to light.

However there are other applications in microscopy where it cannot be assumed that the specimen is transparent or able to be ground to a thickness small enough for light to traverse it. Some materials are opaque even at thicknesses of few microns.

The only solution in these cases is to rely on reflected light. For this to be possible, a different illumination system is required on a microscope. This type of illumination is commonly designated of epi-illumination (as opposed to trans-illumination used for biological observations). This is where a device known as vertical illuminator comes into play (picture obtained from a Olympus BHM manual):

This device provides light to the specimen by guiding a beam of light from a separate source (a tungsten filament, xenon bulb, or LED) through optics (see the principle of Köhler illumination) and into the microscope tube towards the objective. So with this approach, light travels through the objective in two different directions: the light that goes down to illuminate the specimen, and the reflected light that travels upwards into the ocular for finally being viewed by the human eye or by a camera.

As both transmitted and reflected light are mostly perpendicular to the specimen, this technique provides a very homogenous illumination of the specimen, without shadows, similar to the transmitted light microscopy.

This is ideal for example in the semiconductor industry, where very clear and consistent images of the specimens are required.

As I have documented in previous posts in this blog, I had acquired a Olympus KHC biological microscope a couple of years ago, for which I had to do some reconditioning work and an adaptation to operate with LED trans-illumination.

More recently I spent some time looking for ebay auctions in order to find a vertical illuminator suitable for this type of microscope. Waited a while until I could find a proper deal. After over a month between shipping and customs, finally it arrived.

As I expected it did not include some of the elements that constitute the complete kit, such as the light housing and filters (polarizer, ND filters, etc).

The unit came somewhat dirty, so that it required comprehensive cleaning until it could be used properly.

One of the things I first looked into were the defocusing optics near the light input. These had a considerable amount of dust, and as such decided to disassemble the part and clean the individual lenses:

Essentially there were two converging lenses separated by a spacer, and a clear glass separated by another shorter separator. From closer analysis of the clear glass, it appeared that there were traces of a coating in the edge of its surface. It appeared that this coating wore off over time, eventually due to the heating.

Also removed the tube that holds the polarizer and filters (by undoing a total of six screws -  three between the tube and an intermediate part, and another three between the later and the main vertical illuminator assembly):

The main assembly was also quite dusty inside. One thing that at a first glance worried me was the fact that the black tube that protruded from the assembly would be too long for this microscope:

Fortunately it could be unscrewed:

Therefore allowing the vertical illuminator to be assembled into the microscope. One outstanding concern would be the impact of not having this element (e.g. reflections inside the tube), but more on that later..

In order to clean the main assembly, the only option was to tear it down completely, and clean its individual mechanical components and optics. Started by the bottom, removing the threaded ring that attaches to the microscope, and the black circular part with the orifices for the light path.

With the removal of the last part, the interior becomes accessible:

The optical assembly could not be removed without first undoing the darkfield / lightfield control rod:

The optical assembly is made up of a half-mirror (for lightfield) next to a regular mirror with a clear opening in the center:

The darkfield section also includes a clear glass with a light blocker at the center. The brightfield section has a convergent lens instead:

The entire assembly is supported by a rail, through which it slides between darkfield and brightfield, as the user pulls or pushes the rod:

On the other side of the main assembly sits the ring for controlling the analyser angle (as opposed to the polarizer, which is placed in the previously described filter assembly). Also disassembled this ring, in order to clean and re-lubricate it:

It is composed of a inner black ring with the control rod, an outer silver ring that attaches to the main assembly chassis, and an outer ring which is the dial for setting the analyser angle.

After all the cleaning and lubrication was completed, assembled the device, and mounted it into the microscope. It was now time to start doing some test observations:

The only problem still, was the fact that I did not have the light housing that would mate to this vertical illuminator. Improvising would be required...

As such, grabbed the 100 Watt LED lantern (a previous DIY project) and put it close to the light input:

This allowed for doing some crude observations, for example of this Pentium processor die:

Using the 100x MPlan objective (0.90 numerical aperture), it is possible to visualize structures at roughly 1000x total magnification, revealing transistor scale details such as the traces and vias:

Or for example the recording pits on a pressed CD-ROM:

Or the laser-etched labels in the centermost area of the CD:

The next step is to continue the construction of the LED light housing for this vertical illuminator. This will provide a more convenient and consistent light source. It is still work in progress, especially from the mechanical point of view. More details to come:

Sunday, September 2, 2018

4-wheel adventures ranging from customer relationship to automotive hacking

1. Context

Since more than a decade ago, automotive technology have captured my interest to some extent. Not so much in the mechanical domain, for which the industry have in most part been over the years conservative and slow in pushing inovation, but mostly in respect to the digital framework that integrates the vehicles. This overlay of digital technology plays a fundamental role in modern cars, ranging from safety, fuel economy, controlling the production cost (by reducing the number of individual parts), emissions control, comfort and entertainment.

The proposition that a new car represents is to a great extent defined by the technology that is behind, which serves to enrich the user experience, to provide unique features, and also to make sure that the vehicle complies with the safety standards that are in place in the geographies where the vehicles are sold.

In spite of an effort to standardize much of the integration that exists between the electronic components of automotive vehicles, there is a broad domain of protocols and data formats which are manufacturer-specific and that are rarely shared with the public. An important part of the standardization that began taking place since the 1990's have been largely driven by the introduction of regulation to enable emissions testing, notably teh suite of OBD (On-board Diagnostics) related standards. These include:
  • SAE J1850
  • SAE J2284
  • ISO 8093
  • ISO 15765-4
  • ISO 14230-4
On top of the standards (which among other aspects define communication transport layer for messages between controllers and/or diagnostics tools) are the vehicle module specific commands and parameters.

Only a small slice of these commands are covered by the standards, as is the case of the OBD-II/xOBD problem code (PID) lookup process. These and a limited set of realtime monitored parameters are well documented and covered by the standards, and in general every car manufacturer must provide the OBD-II port, and implement this common set of commands.

2. Initial experience

The first peek I took into understanding OBD, was to manually build an interface after having enrolled in ELM Electronics beta testing program of one of their firmware releases. They have shipped me (free of charge) a PIC microcontroller flashed with a beta version of their firmware.

I was able to play with the tool, at the time using a Fiat Idea 1.4 as a test platform. You can check my blog post from that time:

What I could capture since then, is that not much went on in the way of this industry becoming more open source. On the contrary, most of this industry remains closed, with niche markets of companies providing expensive tools for professionals, and another tier of companies providing cheap tools to consumers, which appear in most part being developed based on reverse engineering and leaked information from the manufacturers.

The opensource comunity have however received very little contribution from developers and engineers seriosly commited in producing and sharing knowledge in this domain.

3. Recent experience with a VCDS competitor - OBDeleven

Recently, mostly out of curiosity and some practical necessity, I have acquired a device called OBDeleven, which is produced by a company called VoltasIT (based in Lithuania). This is a tool that is specific to the VAG group vehicles, and is designed to be used with their Android app. It is a relatively cheap proposition, compared to equivalent tools such as the Ross Tech VCDS (formerly VAG-com).

The device attaches to the OBD-II diagnostics port, and integrates a bluetooth chip which pairs with the smartphone.

From a quick teardown and looking at the chips it is very similar to the ELM interface I built 10 years ago: one PIC18F25K80 microcontroller:

 a CAN transceiver (in this case a NXP TJA1040):

and a few other bits and bobs (voltage regulator, diodes, etc):

The bluetooth radio is clearly of a very cheap type, given the fact that these share the same dodgy bd_addr (it should be unique per device).

Putting the hardware aside and ignoring the inflated price for a device that is mostly the same as a typical ELM327 clone that can be bought from China for 5 €, the software has a very useful set of features, and apart from some kinks is well put together.

The approach of monetizing the more complicated and risky adaptations (which they call apps - within the app) is also interesting, while still giving the user the basic tools for making the changes (at his own risk) by himself.

At least in the VAG domain, there are three configuration domains which are made available via the OBD interface (this was interpreted and summarized from forums and other sources online):

  • Coding (long or short) - a given byte array which contains an assortment of flags, enumerated types and other types of values. It usually encodes the features that are made available in a particular unit (car) that goes through the assembly line. Unless hardware is added or removed from the vehicle later in its lifetime, the values are not expected to be changed. The coding being considered long or short depends on the size of the byte array. Some control modules do not provide many customizations, and as such the byte array is short;
  • Adaptations - individual settings that are stored in the control modules, which can consist of calibration data or features that can be enabled for a particular market or specific sale. These can be changed by the car dealership as required;
  • User defined settings - these are the changes that the user can perform himself (e.g. via the infotainment menus or instrument cluster). For example tire pressure warnings, tire pressure reset, speed warnings, interior lights, infotainment sound controls, trip distance, etc. Usually the user can change these settings to the factory defaults.
This tool enables the access to the first two, and also has convenience features like having a list of access codes which are common for having write access to the adaptation or coding changes.

Also the tool can read a myriad of realtime data (well beyond the OBD standard), the can range from the current temperature of the infotainment CPU, to the calculated amount (in grams) of sooth in the Diesel Particulate Filter, plot charts and export the data to CSV.

4. Dealership episode and outcome

Recently I had an episode of taking the car to the dealership for a rear bumper fix because I was rear-ended in the highway, and by mistake I left the OBDeleven dongle in the socket or stored in the glove compartment (I am not sure). The fact is that I noticed the dongle disappearance right after leaving the dealership.

Upon talking to them and complaining about the disappearance of the adapter, they were unable to find it and proposed to compensate me with one of their official dongles, the VW DataPlug:

At time I found that pursuing proper compensation would be a hassle, and this would be better than nothing.

Later I read online that at least in some markets the VW dealerships were giving away these dongles for free during 2017.

5. Reverse engineering

Anyway this could be an interesting dongle to analyse, and later I could consider reselling it in order to at least recover part of the value of the OBDeleven.

The first impression of the physical dongle (the DataPlug) was that of a product made according to automotive standards (high temperature plastics and precision made rugged casing):

It is produced by Texa, an italian manufacturer with a comprehensive portfolio in automotive tools (

The OBD connector even has a metal locking plate:

Very different from the OBDeleven, with its cheap plastics and conventional PCB materials and assembly.

Regarding the chipset, it was physically undecypherable, but judging by the package aspect and pin count these would be more sophisticated devices than in the OBDeleven:

There are 3 main devices. A larger one marked with 52102A 115U7231A:

 a smaller BGA package next to it, with the references F4150G6 A500GVQ TWN7332:

And the bluetooth chip, which is the only identifiable of these 3 chips, a Cypress CYW20713 Single-Chip Bluetooth Transceiver:

Given that the dongle has an FCC ID  - T8RDP15, I was able to lookup online in the official FCC site:

From there I could find in the user manual that the device has the following specifications:

ARM Cortex M4 CPU (168MHz)
Total Flash: 1024 Kbytes FLASH 
Total RAM: 196 Kbytes RAM

And it conforms to the following directives and regulations:


R&TTE 1999/05/EC
RoHS 2011/65/EU

Product regulations:

EN 301 489-1V1.9.2:2011
EN 301 489-17V1.6.1:2013
EN 300 328-2V1.8.1:2012
EN 60950-1:2006/A11+A1+A12+AC:2011
ISO 7637-1:2002
ISO 7637-2:2011



In sum is a much superior device to the OBDeleven.

The design and architecture details of the software and dongle were requested to be made confidential by Texa to the FCC, and as such are not published.

During the analysis I have attempted to grasp more details by looking at the disassembled APK from the Volkswagen Connect app, but given the obfuscation and lack of time I did not went deep into taking conclusions. I was able see that their communications library uses Java bindings that are created from protobuf. As expected the original protobuf grammar files could not be found in the package.

I also enabled Bluetooth HCI sniffing on the handset, and inspected some of the communication between Android device and the dongle while I was using it in the car.

Again it was difficult to take conclusions, but it appeared that no encryption was taking place on top of Bluetooth own security, as some expected plaintext such as the car odometer Km could apparently be found in the payloads. I could not decypher the VIN number, but it is possible that it would be encoded differently. Certain headers such as 17 03 03 00 seem to repeat across different responses from the dongle, and the payload 0B FF 01 06 86 apears to repeat in many of the requests:

It does not seem to have any known protocol on top of RFCOMM (such as SPP). Also the pairing normally fails when attempted directly from an Android device or some other system such as Windows or Linux running bluez.

In spite of the challenges that may represent, this could be an interesting alternate device for building applications on top of. For example something with the potential of OBDeleven but without the constraints and reliability issues, such as the risk of battery draining that occur in the later, due to poor power management capabilities and/or bad implementation (it is not because of the device itself, but from the control modules that the dongle prevents from switching to sleep mode). The VW DataPlug does not appear to have this problem.

Sunday, July 15, 2018

After-market safety treatment of low cost products

There was a time when it was not possible to obtain a proper pure sine wave inverter (12 V DC -> 220 VAC 50 Hz) without shelling out hundreds of Euros or USD.

Today, with the massification of supply and demand, and with the sheer scale of the chinese industry producing these types of devices for consumer and industrial applications, prices necessarily went down.

Until recently I had a modified sine wave inverter, which given its limited compatibility with different types of loads, I have discarded (resold) and went looking for a cheap pure sine wave (which intuitively I expected to be much cheaper in current days).

Through Aliexpress, I found a 500 Watt/1000 Watt peak for 38 Euros (roughly the price I paid for the modified sine wave model years ago - and it was only rated to 250 Watts):

As for everything that satisfies the following 3 criteria:
  • is cheap;
  • is unbranded/not from a known brand;
  • is produced in China.
I normally don't feel entirely comfortable with using products in these circumstances without running a teardown first, and looking closely if everything is put together properly, and according to a minimal set of safety rules.

Regarding the later criterion, it is not based on pure blind prejudice, but based on experience with products sourced by this market (especially the low cost ones tha  come without any type of warranty).

In this case, and because it involves some risk to humans (220 Volts output can be harmful/lethal), I decided open it up and see if everything was being done correctly.

The first thing I noticed was the lack of insulation in the mains socket wires (which provides the 220 Volts output) and in the power switch (which puts the inverter in standby):

Also these wires did not have a very impressive section (even though at 500 Watts will only need to be rated for 3 Amps or so), so went on and replaced these with thicker wire, and insulated the terminals with heath shrink:

The second thing was tha back of the main PCB which did not seem to have taken any type of cleaning after the manual soldering that was probably done on top of the traces that carry the most current (the primary side of the inverter).

For this, had to spend some time flushing all the resin (or wathever substance) with isopropil alcohol from the back of the board, until it was properly clean.

The other thing was the lack of creepage distance between the two mains terminals in the PCB, which I fixed by drilling a gap between these:

And finally, between the bottom of the PCB and the chassis (made of extruded aluminium and treated/anodized with a very thin layer of black paint) there wasn't any kind of insulation.

Added a plastic film to the chassis wall in order to improve insulation:

Apart from that could not find anything terribly wrong with the design. It would have certainly been more reassuring to see it more inspired in SMPS designs, with proper separation between "cold" and "hot" sides, and creepage distances being followed wherever possible.

It is true that even though the output voltage is high and harmful, it still is not at the same risk level as mains connected devices (where it is assumed that surges may occur). This may explain some tolerance factor here, or it is simply a domain that went forgotten and not properly regulated.

Regarding the components it was somewhat of a positive surprise to find brands such as Microchip, Texas Instruments or International Rectifier in the mix.

The PWM modulator (which modulates the 50 Hz sine wave for the output) seems to be properly implemented in a nice separate module controlled by a Microchip PIC16F716:

The output H-Bridge is made of four FHP13N50 high voltage MOSFETs:

And on the input side we have four FHP3205 high current MOSFETs:

All in all it is not a bad package if it weren't for these "small" details. This adds to the observation that many chinese products are "almost good", suggesting that some oversight (or deliberate gaps) seem to exist in the production line of these products.

An equipped consumer like myself will grab a product in these conditions, and perform an after-market treatment to render the product safe to use or reliable.