- Joined
- Jul 27, 2007
- Messages
- 3,642
- Points
- 63
It's more likely than you think 
For the Scientech 36-5002T2 anyway.
This project started as a request that saw my past involvement with LPMs and asked if it was possible to add datalogging to his LPM he ordered from Daguin. I agreed, imagining adding a board I had originally designed for a digital Radiant LPM that was never released.
The LPM arrived, I hooked up the analog output to my test setup and wrote up a basic test program. Then I grabbed a laser and pointed it at the sensor. The results were....bad. The value spiked way up but then rapidly trailed off and continued testing gave unreliable results.
I managed to find a manual for the series of LPMs and found the lovely tidbit in the writeup about the analog output that said effectively that the rear analog output was uncalibrated, it was all done in the processor of the LPM. Also interesting to note is that the series is actually natively datalogging capable, although the option wasn't purchased for this specific meter. I probed the associated output pins of the microcontroller anyway but they were inactive. (along with an unpopulated RS232 transciever chip)
So I decided to change gears; if the data wasn't available as an analog signal perhaps I could snag it digitally somewhere. Sniffing data on the ADC bus was out since it would be prior to calibration (stored in an EPROM on the board). So I looked at the display controller. Looking up the datasheet I found it to use a super simple serial input protocol: the CPU simply sends a string of 35 bits over a synchronous data bus to the display driver chip, the chip then turning out the respective leds in the 7 segment displays on the front of the meter. If I could grab that string of bits as it goes to the display driver I could reconstruct the numeric values and send it to a PC.
So I had a plan. I got out an Arduino from my parts bin and used my soldering iron to tap into the pins on the display controller for the serial data, serial clock and ground. Wrote up some code to grab the bits whenever the data was valid.
I started to receive data, but it wasn't regular and seemed to sometimes skip some updates of the LED display. Hooked up the data lines to my oscilloscope to find that the data was clocked at a pretty fast rate and that there were other devices on that data bus. The Arduino only had a few microseconds to grab the valid data before it flew by. The little atmega168 running at 16MHz just wasn't fast enough to grab the data with the C++ environment overhead of the standard programming language.
I bumped up my CPU horsepower to a Freescale Semiconductor[SIZE=-1] MK20DX128 32 bit [/SIZE][SIZE=-1][SIZE=-1]Cortex-M4[/SIZE] ARM processor clocked at 48 MHz[/SIZE]. Success! Data was being reliably read and I could begin making a bitmap to convert strings of ones and zeros back into decimal numbers from the 7 segment LED format.
For the Scientech 36-5002T2 anyway.This project started as a request that saw my past involvement with LPMs and asked if it was possible to add datalogging to his LPM he ordered from Daguin. I agreed, imagining adding a board I had originally designed for a digital Radiant LPM that was never released.
The LPM arrived, I hooked up the analog output to my test setup and wrote up a basic test program. Then I grabbed a laser and pointed it at the sensor. The results were....bad. The value spiked way up but then rapidly trailed off and continued testing gave unreliable results.
I managed to find a manual for the series of LPMs and found the lovely tidbit in the writeup about the analog output that said effectively that the rear analog output was uncalibrated, it was all done in the processor of the LPM. Also interesting to note is that the series is actually natively datalogging capable, although the option wasn't purchased for this specific meter. I probed the associated output pins of the microcontroller anyway but they were inactive. (along with an unpopulated RS232 transciever chip)
So I decided to change gears; if the data wasn't available as an analog signal perhaps I could snag it digitally somewhere. Sniffing data on the ADC bus was out since it would be prior to calibration (stored in an EPROM on the board). So I looked at the display controller. Looking up the datasheet I found it to use a super simple serial input protocol: the CPU simply sends a string of 35 bits over a synchronous data bus to the display driver chip, the chip then turning out the respective leds in the 7 segment displays on the front of the meter. If I could grab that string of bits as it goes to the display driver I could reconstruct the numeric values and send it to a PC.
So I had a plan. I got out an Arduino from my parts bin and used my soldering iron to tap into the pins on the display controller for the serial data, serial clock and ground. Wrote up some code to grab the bits whenever the data was valid.
I started to receive data, but it wasn't regular and seemed to sometimes skip some updates of the LED display. Hooked up the data lines to my oscilloscope to find that the data was clocked at a pretty fast rate and that there were other devices on that data bus. The Arduino only had a few microseconds to grab the valid data before it flew by. The little atmega168 running at 16MHz just wasn't fast enough to grab the data with the C++ environment overhead of the standard programming language.
I bumped up my CPU horsepower to a Freescale Semiconductor[SIZE=-1] MK20DX128 32 bit [/SIZE][SIZE=-1][SIZE=-1]Cortex-M4[/SIZE] ARM processor clocked at 48 MHz[/SIZE]. Success! Data was being reliably read and I could begin making a bitmap to convert strings of ones and zeros back into decimal numbers from the 7 segment LED format.
