Reverse engineering this wave form

[FrankT]

I am trying to reverse engineer a laser range finder.  The device has a controller board, and separate LCD and laser modules connected by FFC.  I built a breakout PCB to sit between the controller board and the laser module so I could spy on the signals.

The first attachment shows a close up of the some of the data signals.  I'm assuming channel 0 is the clock (about 166kHz) and the data is channel 1, and the data sampled on the rising edge.  The data is transfered in 24 bit words.

The second image is zoomed out to show more data and some other control signals.  There only appears to be one data line, CH01. 

You can't see it in the image, but CH03 goes low just before the last word of the first burst, then high part way through the second burst.  My guess here is that CH03 is the direction. 

Originally I assumed CH02 was chip select, but clearly this waveform is shows it is not.

I have no idea what CH04 is.

So, questions...

Does any recognise this as a standard protocol?  I've been reading using SPI, but without a proper CS, I usually end up with shifted bits.

I think I smoked the main controller, so I'm going to have to drive the laser module myself now.  Is there an easy way check if a pin is an input or output?  Or do I need to just put resistors on all my IO lines and watch my power supply for current spikes?

Frank

[amyk]

Do you have the datasheets for the parts? First thing to do is get as much info on the individual ICs as you can before looking at the system as a whole.

You should watch Mike's reverse-engineering video if you haven't already done so.

[Memphis]

In SPI, some design can be one way, usually from master to slave. The CS signal is not must have, it can be permanently on. So yes, it can be SPI, and it looks like so.

[FrankT]

Do you have the datasheets for the parts? First thing to do is get as much info on the individual ICs as you can before looking at the system as a whole.

You should watch Mike's reverse-engineering video if you haven't already done so.

Thanks, Mike's video was very useful.  Unfortunately I didn't stick my product down and I think I trashed the FFC cables.

Unfortunately, I couldn't find any of the chips online, so I'll try and persist and try to drive it with what info I have.  I have full captures of the start up and run sequences, although I still can't see a distance measurement in the packets that are be transferred.

Frank

[mikeselectricstuff]

Do you have the datasheets for the parts? First thing to do is get as much info on the individual ICs as you can before looking at the system as a whole.

You should watch Mike's reverse-engineering video if you haven't already done so.

Thanks, Mike's video was very useful.  Unfortunately I didn't stick my product down and I think I trashed the FFC cables.

Unfortunately, I couldn't find any of the chips online, so I'll try and persist and try to drive it with what info I have.  I have full captures of the start up and run sequences, although I still can't see a distance measurement in the packets that are be transferred.

Frank

Some photos may be useful.

[kxenos]

Is it possible it uses something like this?? datasheets.maximintegrated.com/en/ds/DS1861.pdf
The signals IMO resemble an I2C bus with some extra control lines

[FrankT]

Some photos may be useful.

The first picture is the whole assembly from the device (an early model prexiso - the 4 button model).  The large chip seems to be the main mcu that drives the lcd and controls the laser module.  It's got "38024B83HV, LEICA, 752912 S 0643, AK05657" printed on it.  You can see the LM317.  The board uses 5v and 3.3v so I'm guessing the little ICs are that.  The other chips are an LCX14 (Hex inverter) and a 93c56 (serial eeprom).  The main board seems to get its clock from the laser module.  One of the lines is a 3.4v 10MHz square wave.

The second picture is the laser module itself.  When I saw it was a nice self contained module, I thought it would make a great range finder for a robot.

The third picture shows the laser module PCB.  It's not very well focused.  The picture is taken through my magnifying lamp.  That's the only way I can light the object uniformally.

There's not much I can add to describe the picture.  The blobs of solder below the "Jump V4.0" text is where the laser diode is attached.  This needs to be desoldered remove the PCB. (which I should not have done because I think I've messed up the alignment).  On the underside of the board is the optical sensor - it's tiny, probably 3x3mm with no markings.

I've searched for the main chip, "0723, 758201, 064906, 00 06" but I couldn't find anything.

[amyk]

ASICs... I can't find any info on those numbers either.

The QFN28 on the laser module might be a standard OTP MCU with a custom part number; anyone know of one that has the xtal on pins 1 and 2?

[BiOzZ]

i dont think its an i2c bus ... the clock does not look like it matches up with the signal ...

[kfitch42]

i dont think its an i2c bus ... the clock does not look like it matches up with the signal ...

I agree it isn't i2c, but mainly because we can see Ch01 is low during the idle state. i2c requires pull-ups so that both lines go high when idle.
Ch00 could still be the clock for Ch01, if data is sampled on the rising edge (as was stated by OP). Ch01 never changes near a rising edge on Ch00.

[kfitch42]

The data is transfered in 24 bit words.

Silly question: What is your evidence for that?

I've been reading using SPI, but without a proper CS, I usually end up with shifted bits.

Are you using a micro with SPI, a Bus Pirate, or something similar?

For CS you just need something that goes low when Ch00 goes low, and stays low for ~4ms ... 555 to the rescue? Basically, you want a 'trigger hold off', right?

Can you get your LogAn to decode? Can it spit out .csv files that you can decode in matlab/octave/excel/python...? Then at least you could start looking at the protocol for patterns (common header/trailer...) even if you couldn't interface with it in real time yet.

[FrankT]

The data is transfered in 24 bit words.

Silly question: What is your evidence for that?

You can't see it on either of the captures, but after 24 bits, there was a significant gap in the clock stream.

I've been reading using SPI, but without a proper CS, I usually end up with shifted bits.

Are you using a micro with SPI, a Bus Pirate, or something similar?

For CS you just need something that goes low when Ch00 goes low, and stays low for ~4ms ... 555 to the rescue? Basically, you want a 'trigger hold off', right?

Can you get your LogAn to decode? Can it spit out .csv files that you can decode in matlab/octave/excel/python...? Then at least you could start looking at the protocol for patterns (common header/trailer...) even if you couldn't interface with it in real time yet.

I started with my USB scope, exported the captured  data as CSV and decoded it with a perl script.  My scope only has 32k of sample memory so, to see more, I wrote a microcontroller program to read SPI and send it back to the PC over USB.

This is an example of some of the data that was captured (the timestamp is when the PC received it)...

Code: [Select]

40:52.427 b00001100001d00001d00b40304800b0faa0701000480002c8100028faa4100000
40:52.433 b00001100001d00001d00168308800b0fa20700001480002c8000128fa24100000
40:52.439 b00001100001d00001d005a0304800b097a0702000480002c820002897a4100000

These are the packets I saw on the usb scope.  I thought they were distance data, but although I could see a clear pattern of bits changing, I couldn't interpret them as a distance.

This pattern was also similar to the start up sequence, so I hacked up a driver and sent this to the module and it turned the laser on!

Another pattern I received that I never saw on the scope was this...

Code: [Select]

f9000068efc068efc068e02068e82068e42068ec2068e22068ea2068e62068ee2068e12068e92068e52068ed2068f52068e52068f92068c52068e52068d52068952068e52068a52068652068e520

But again, I couldn't interpret it.  There's clearly a pattern.  I though it was masked with an xor pattern, but that still didn't show anything...

Code: [Select]

f90000 68efc0 68efc0 68e020 68e820 68e420 68ec20 68e220 68ea20 68e620 68ee20 68e120 68e920 68e520 68ed20 68f520 68e520 68f920 68c520 68e520 68a520 686520
       000000 000000 000FE0 0007E0 000BE0 0003E0 000DE0 0005e0 000da0 0009E0 000ee0 0006e0 000ae0 0002e0 001ae0 000ae0 0016e0 002ae0 000ae0 004ae0 008AE0

I'm starting to think that there may be 2 devices on the SPI bus that are selected with the other lines.

Unfortunately, I've really wrecked the FFC cables on the device so I can't run it and trace anymore.  Both FFCs were soldered to the main board.  One I can replace with a connector.  The other has to be stripped back and resoldered, so the whole project has been put in the "too hard basket" for now.