Category: Reverse Engineering

Everything started when i replaced the brushed motor of my mini lathe with a new higher torque (from far East) brushless dc motor. It was for sale as a replacement part for sewing machines but did a great job for the mini lathe. There was no cutting force that could stop this motor.

On a rebuilt that i did on my mini lathe and as i had everything teared down i thought it would be a great idea to add some extra features to my brushless dc controller. Features like the option to stop/lock the motor in a specific position or turn it a specific number of degrees or even get the servo position encoder readout and use it to control a step motor for driving the leadscrew which thereinafter will automatically cut threads without the need of manually gears changing in the gearbox. (This is another ongoing project for automatic thread cutting which included an extra rotary encoder for the spindle positioning). “Kill two birds with one stone”.

So i start looking the controller PCB ( OD-P05-001-54 F2H0794-A0 UIDO or ODIN depending on which orientation you read it ) trying to understand how it operates.

It looked to have an onboard SMPS, some drivers and fets for the H-bridge, some logic gates and schmitt triggers and a central microcontroller to control everything onboard. The mcu has a label of 8132Z008 0C022 with no available information online. At least all my searches didn’t return any useful information. Nearby the mcu there was a pinhead 3×2 and measuring the voltages across the pins it gave a good chance to be an AVR ISP. I thought it would be a good idea to connect the AVR ISP and try to read this MCU and check if there is a known AVR under this package or at least a copy of. Since the voltage and ground pins where aligned there was no chance of short circuiting something that will make the magic smoke. So everything was straight forward.

I connected the AVR ISP between my (charging) laptop and the PCB and…. i plugged the PCB to the mains power.

……

……

Everything went black! I was wondering what did go wrong? I unplugged it from the mains and i walked down to the electrical panel. The Earth-leakage circuit breaker (ELCB) and the circuit breaker of the mains plug interrupted the mains! WoW! It looked to be something serious! I reset the ELCB as well as the circuit breaker and i started looking for the cause. I realised that the laptop was shut down! That was a really bad omen. Fortunately pressing the power on button boot the laptop normally. It seemed to have minor losses and of course lessons learned! Never again an electrical device mains powered connected to my tools without an isolation transformer. This was also the reason i built an isolation box with 1:1 transformer, a fuse box and a seperate ground banana plug to connect it only when needed.

On the PCB nothing seemed to get blown so i tried to power it on with nothing connected on it and yes it did power up but it didn’t function any more. The shock was big enough to blow the mcu.

Still, it wasn’t clear to me what happened. It looked to me for a short circuit from the PCB to the earth’s ground but what was that? And the adventure just began. There was no choice anymore from reverse engineering the controller and understanding how it did work and then try to build a safer and more robust controller implementing all of my extra requirements/features.

Step by step using my multimeter and supplying the PCB with 5Volt on VCC pins when required i started reverse engineering it. After two weekends of work here you have all the outcome of my spent hours in schematics.

We start with the power supply

The power comes from the mains passed through a huge safety fuse of 10A ! i don’t know what is going to get blown first here. Then there is an X2 capacitor and the Rectifier. Following the rectifier a 500 Ohm 1watt resistor is used to slow charge the two in series electrolyte capacitors of 680uF/250WV during startup. As i can imagine they are used in series to increase the voltage rating. Just a few milliseconds after startup Relay1 arms from the 15Volts produced by the SMPS (not yet discussed) and the RT1 is by passed. This is it. The output is a ~ 330V not isolated DC power. This is the BLDC (brushless DC) motor High Voltage used in the H-bridge. Believe it or not. The – (minus) of the mains full wave rectifier is directly connected to the PCB digital ground! Is something coming to your mind? I don’t know about you but i already make some imaginations… When i connected my AVR ISP onboard actually i did connect the – (minus) of the rectifier to the earths ground through my laptops usb. It doesn’t sound that safe does it? By connecting the minus of the rectifier to the earths ground, means that the mains is shorted to ground on each negative cycle of the AC. About 50 times per second for a 50Hz mains. This is the first design i see with no mains isolation. Attention! The same could have happened if i was trying to probe the circuit with my oscilloscope hooking the scopes ground on the digital circuit GND for reference.

Following the 330V DC we meet the SMPS that i did recognize on my first look but unfortunately i wasn’t so suspicious to take a closer look and see that there was also a second not isolated power. I imagined that everything was powered from the output of the SMPS.

On this smps there are two secondary windings producing 5Volt and almost 15Volt (14.7 measured). The 5Volts are further regulated by the TL431K linear regulator . I think there is no need for any further analysis here.

Close to the SMPS there was an optocoupler with a transistor and a higher wattage resistor that caught my eye.

It looked to be something separate from the SMPS but neither a piece of the digital circuit. After some continuity measurements i found that this was a circuit that grabs the mains frequency and supplies it in TTL Voltage levels to the digital circuit and specifically to the MCU directly.

Could this be a clock for some operations? Or maybe a way to identify if the board is powered by 110V/60Hz or 220V/50Hz mains power and adjust the duty cycle of the H-bridge? I don’t know but make guesswork as the mcu has gone and i can’t take real measurements on the PCB while running.

Turning to the Digital side i started by reversing the side of the Servo Encoder received signal path.

The encoder consisted of 3 pin outputs. The signals once on board are pulled up by resistors and decoupled by capacitors. Then they are passed through a schmitt trigger/inverter (74HC140A) twice to clear and invert twice the signals. The output of the schmitt trigger feeds directly the MCU where the MCU can identify the position of the motor’s rotor. These signals also feed two XOR gates (74HC86). My guess is that these gates are used to create a pulse output corresponding to the motors rpms. Then it could be used a dedicated hardware MCU interrupt just to count the motor rpms and the 3 encoder signals when there is the need to know the position of the rotor. Maybe on the startup sequence?

On the side of the H-bridge circuit there was an IC standing out from the others with some resistors around it.

A closer look showed me that U6 is an LM393 with two Op-Amps inside. My first guess was that this comparator is used to adjust the supplied voltage to the motor but after drawing the circuit on paper i realised that this should be an over current protection. A cheat to this was the R31 R015/3Watt resistor nearby which drove me to the conclusion of the overcurrent protection even before finishing the circuit drawing.

The R31 is used as shunt resistor. One side is connected to Ground and the other side is connected on low sides of the H-bridge so it can sense the current draw of each motor phase. The first op-amp is used to compare and sense the current and the second/followed one is used to convert the output of the first one to the logic level of 0-5V (open collector output). Something like analog to Logic converter. Running this circuit on spice it results that overcurrent protection is active High when current load is more than ~ 2 Amperes across the shunt resistor. The mcu pin on the other side could be there as an analog input to also read the current sense voltage drop but i’m not sure for this.

And now the real thing.

The H-bridge and it’s driving circuit.

Starting from the MCU side, the signals are first pulled up. Then depending if they drive the High side of the H-bridge or the Low side they are feed to a NOR (74HC02D) or OR (74HC32D) accordingly. These gates are used in combination with the overcurrent protection to directly cut off the driving of the H-bridge in an overcurrent detection. HIN, is active high but LIN is active low. Using a NOR gate on High sides when the overcurrent is on the one side of the NOR input is going to be High resulting always an output of logic 0 which means the H-bridge High side to be deactivated. Respectively using an OR gate on the Low sides when the overcurrent is on the one side of the OR gate input is going to be High resulting always an output of logic 1 which deactivates H-bridge low side which is active Low. For driving the H-bridge transistors the ID5S606 have been used which seems to be also far East ICs. The transistors on the bridge are the XNF15N60T described as Trench-FS IGBT with the characteristics of 15Amper, 600V and VGE=5V2.

The motor itself needs some reverse engineering as there are no available characteristics of it.

Out of curiosity i disassembled it to see the encoder implementation and measure the wire thickness used for the windings to determine what is the maximum amperage it can handle.

Here we see the 3 hall effect sensors used for the rotor position detection
I also soldered this extra Red wire at the center point of the Star for any possible future use. Just in case.

The encoder consists of 3 hall effect sensors positioned internally between the windings (as seen above) making it clear that all three are used for the positioning of the rotor and there is no index signal.

The output of the encoder is:

Blueu000111000
Yellowv110001110
Whitew011100011

Which corresponds to 6 steps of 60 Degrees.

The rotor consists of 6 neodymium magnets as seen above.

The winding wire thickness is measured to 0.51mm so it is a AWG24 which means a maximum load of 3.5Amper. The resistance between two phases is 5.2 Ohm (59 meters of wire?) and the inductance is 19mH. These in comparison to the 2 Ampere overcurrent control reverse engineered above will guide the design of the new servo controller.

Stay tuned!

It has been two years since my last post as i can see from the date but finally it seems i found the time to come back. The idea of reverse engineering the car parking sensors came when i replaced my car parking sensors and i was curious to find out how this thing really works. 

Generally, i had a picture in my mind on how they should work. A sounder that sends the sounding and a microphone/receiver that receives it back (as radar works), calculating the time, the signal takes to travel from the sounder and back to the microphone from the obstacle reflection. Having 4 sensors on the car bumper pointing to the same direction, is challenging for the processor to recognize which sounding comes from which sensor. A quick thought i made is that it may use a different operating frequencies for each sensor or a different timeslot for each sensor keeping the same frequency for that purpose. But we will find out later on, while powering things on.

So having this picture in mind we move on.

First interesting thing that got my attention while i was removing the sensors from the bumper was the sensors themselves. They had only two wires each so the picture in my mind with a separate microphone and sounder on each sensor should change to one device which may switch from sounder to microphone and vice versa (operating both as a sounder and microphone). All this because there are only two wires so there could not be two different components such as a sounder and a microphone. If that was true there should be at least 3 wires, 2 wires one for each component (sounder & microphone) and a shared wire for the common ground. 

Second step as long as i made the first optical investigation i unscrewed and removed the enclosure of the main processing unit in order to have direct access to the PCB design. In first look we can see the main processor from Atmel (AT89C2051), a Schmitt trigger (HEF40106B) which may be used for isolating/separating the analog front end from the main processor/circuit, two operational amplifiers (HA17358) with some external components around it which looks like to be used for filtering and amplifying the received reflections and a third IC which after some googling i found out that's an analog switch (HEF4066B). I can't imagine yet what could be the use of this as there could be a lot of uses such as signal scanning between the 4 sensors or for switching each sensor mode from reception to transmission etc. 

Looking closer to the sensor connectors on the PCB we can see that one connection of each sensor is directly connected to ground so the second connection seems to transmit/receive the signals (obvious). Also there is a small transformer connected on each sensor connection which looks to be used for increasing the signal voltage in order to drive the piezoelectric(possible) transducer of each sensor. 

I think it's time to power things on. Connect the main unit to power as well as the LCD screen to the main unit in order to have feedback and know in which step we are working on. Using the oscilloscope i started reading the pins of each sensor connector with the sensors disconnected trying to find a common pattern. At a first look, the waveform coming out from sensor connector 1 looks like a periodic square wave signal.

Trying the connector 2 the signal seems to be the same with the frequency of the square wave remaining at 40.12khz. In more detail i would describe it as a signal of 14 square pulses of 40.12khz repeating about each 160ms. So the device could send these 14 pulses to each sensor, then switch the sensor circuity to receiving mode and wait for the reflected signal to come until next transmission/sounding. But as the frequency of all 4 channels is the same the identification of the reflection (from which sensor the sounding is coming from) it looks that is not implemented using different frequencies. So let's see if there is a different sounding timing (timeslot) for each sensor. Measuring the timing distance between each channel we can see that each channel has exactly 40ms difference from the previous one . 

1st channel signal to 2nd channel signal distance 40ms

1st channel signal to 3rd channel signal distance 80ms

1st channel signal to 4rth channel signal distance 120ms

So these 40ms gaps may be used by the main unit to read the reflections. This also means a frequency of ~6.173Hz (1/160ms). Our first findings since now are clear. All sensors are transmitting on the same frequency but in different timeslots

Next step i tried to read all of the mcu pins and compare them with the function of each pin given by the datasheet. 

AT89C2051

Pin TYPE READING Pin TYPE READING
1 VCC +5V 20 I/O –
2 UART RX 58.82KHZ SQ 19 I/O 40KHZ/6.173HZ SQ
3 UART TX 534.5KHZ SQ 18 I/O 40KHZ/6.173HZ SQ
4 CRYSTAL 12MHZ SINE 17 I/O 40KHZ/6.173HZ SQ
5 CRYSTAL 12MHZ SINE 16 I/O 40KHZ/6.173HZ SQ
6 INT0 SIGNAL SQ 15 I/O 6.173HZ SQ
7 INT1 6.182HZ SQ 14 I/O 6.173HZ SQ
8 T0 (timer 0 external input) 24.71HZ SQ 13 AIN1 –
9 T1 (timer 1 external input) 12.35HZ SQ 12 AIN0 –
10 GND GND 11 I/O 6.173HZ SQ

Pin by pin. 

From pin 1 to pin 5 all the signal readings are obvious and expected. UART pins 2&3 are used to communicate with the remote LCD display which displays the distance from the obstacle and its direction. This interface can be used in combination with an Arduino for any DIY application. Pin 6 is an external interrupt driven pin and we read a square wave input signal which is not periodic and stable which makes it more interesting and moves it closer to the fact that this pin may reads and decodes the reflections (do all the job). There is a stopped snapshot in the following screenshot where you can see the waveform on that pin. As you may notice there is a small gap after the 12th square wave and then follows another waveform. The following waveform is the reflection and changes its frequency depending on the obstacle distance. In combination with an internal timer the MCU can easily calculate the read frequency and make its calculations for the real objstacle distance. 

Pin 7 is also an external interrupt pin but the oscilloscope reads a 6.182hz square wave. We cannot be sure yet if this square wave is coming out of pin 7 or it's going in.

On pin 8 we have a square wave of 24.71hz. On pin 9 we have a 12.35hz waveform which i followed using the oscilloscope and a continuity meter and i came across a very interesting implementation. As it looks Timer 1 is generating this waveform, then it's inverted through the Schmitt trigger it's filtered and converted to a DC signal and then this signal is feed to the mcu RESET pin through the Schmitt trigger again reversing its polarity. By this implementation when the mcu is normally running it's providing 12.35hz which is then inverted, filtered and again inverted as a result to a zero voltage. When something goes wrong with the mcu (crash – infinity loop etc) and the T1 stops generating this frequency the output of all the above implementation is going high triggering the mcu to reset. This is a very clever "hardware" watchdog and it's something i see for the first time. 

Here is the schematic of this implementation 

Pins 16 to 19 look to drive the actual transducers as these are 4 identical pins generating the same frequency as the one i read on the sensors but in different timeslots. 

Finishing with all the pins i tried to move on and check the routing of the all 4 pins of 6.173Khz with a continuity meter and a desktop light in the backside of the PCB. As these pins are 4 in count probably they may have to do with the four sensors. The continuity shows that each of these pins is connected to the Enable pin on each channel of the analog switch. The Analog Switch consists of 4 analog switches each one having 2 pins that can be actually bridged and one pin that's the enable pin and in fact this pin triggers the corresponding switch bridging. Checking the pins of the IC and using the datasheet i found that one pin of all the analog switches is connected to the filter/amplifier and the other pin is connected to the analog front end of the corresponding sensor. So the logic diagram looks as the following. 

The incoming signals from each sensor is coming to the analog switch and the MCU using the four 6.173Hz square waves selects which sensor input wants to be driven through the Filter & Amplifier to the MCU and finally be decoded. As it looks from the above description the Pin7 (INT1) is not used as an external interrupt pin but as an output pin generating a waveform of 6.173Hz. All four 6.173Hz square waves are in different timeslots. 

Here is the 6.173Khz waveform (yellow) in compination with the 40KHz transducer frequency (Red) 

Regarding the transmission path, the soundings are coming out from the MCU pins (40Khz waveforms described above) then pass through the Analog Front End which also amplifies the signal with the transformers and then finally drive the transducer.

Combining all the above findings we can separate the circuits on the PCB as below

In the end i was really curious to see how the sensors look inside and how they are made of. So i tried to tear down or better to brake them down.

As you can see from the above pictures the whole enclosure is filled with an elastic resin something like silicon and just above the transducer there is a soft white textile material like a sponge visible in the photo above. The transducer itself is indeed a piezoelectric transducer which is very similar maybe the same size as well to the ones you can find in the Christmas wishing cards which plays xmas songs when you open them.