Edit: nevermind, I misunderstood and I guess like they don’t need the spectrometer data itself at that rate. I agree with the webcam thing; leaving my comment in place because the Femto-photography thing is cool
By the way. Femto laser are somewhat common nowadays. They are used in eye surgery and microscopy. I even seem papers talking about using them in finger print scanners! See Optical coherence tomography for more info.
Nowadays, they are done with a reflective diffraction grating, some slits and a light sensor. The sensor is either a line CCD or a DLP with a InGaAs Avalanche Photodiode (APD).
The price is mostly due the sensor. Line sensors can cost from tens to thousands of dollars (see hamamatsu S7030/S7031 CCD).
To measure absorbance, a wide spectrum light source is needed (that's why OP's spectrometer has tungsten halogen and deuterium arc). The sun, in some extent, also works for that.
To measure emission, you don't need a light source.
The difficult part is doing the calibration. That can be done with neon light, mercury vapor, etc.
eh, Arduino the library may be too slow, but underlying chip, atmega328, is definitely not. It runs at 16MHz, and most instructions are 1 cycle long (things like jumps are 2).
> Strobe pulse is 5us wide (200Khz) so for reliable sniffing I should read I/O ports at 1Mhz. The best I could do was reading necessary 13 channels at 80Khz.
You don't need general protocol decoder, you need to wait for strobe and capture a byte. And you don't need all 13 lines - most firmwares use same byte sequence for each frame, so you can detect frame start and just count the bytes. A main loop may do:
- Wait for frame start
- Capture a frame worth of data - this is 8192 pixels, which is 1024 bytes, which is a half of total RAM
- Slowly send data over serial.. You will miss a couple of video frames, but this is OK, the picture is mostly static.
And you don't even need assembly - the strobe is 80 cycles long, and it looks data comes every 100uS or so - that's 1500+ cycles! Super slow, even inefficient C program can handle it.
when he tried to use an Arduino for this task. Even using a sped-up GPIO library (as opposed to notoriously inefficient digitalRead), he couldn’t get a readout frequency higher than 80 KHz
This is why the phrase "right tool for the job" exists. As another comment here points out, the MCU in an Arduino is perfectly capable of it, but the software seems to be ridiculously inefficient.
That said, a better device for interfacing this to a PC would probably be the FX2/LP which is commonly found in cheap logic analysers --- it's not clear whether this was actually the type of logic analyser he used originally, but makes perfect sense given its capabilities.
10 comments
[ 2.8 ms ] story [ 30.2 ms ] thread"He decided to tap into the the display communication lines."
Bingo!
I wish I found cool stuff at flea markets. Best thing I ever found was a Palm TX for five bucks about four years ago.
he couldn’t get a readout frequency higher than 80 KHz – with the required IO readout rate deemed as 1 MHz, something else would be called for.
Putting aside the pin with serial data, I'm surprised the best solution wasn't to just point a webcam at the screen and OCR it.
Looking into achievable frame rates though, I guess we can image things way faster than I would have guessed https://en.m.wikipedia.org/wiki/Femto-photography
Edit: nevermind, I misunderstood and I guess like they don’t need the spectrometer data itself at that rate. I agree with the webcam thing; leaving my comment in place because the Femto-photography thing is cool
https://web.media.mit.edu/~raskar/trillionfps/
https://www.youtube.com/watch?v=EtsXgODHMWk
By the way. Femto laser are somewhat common nowadays. They are used in eye surgery and microscopy. I even seem papers talking about using them in finger print scanners! See Optical coherence tomography for more info.
Nowadays, they are done with a reflective diffraction grating, some slits and a light sensor. The sensor is either a line CCD or a DLP with a InGaAs Avalanche Photodiode (APD).
The price is mostly due the sensor. Line sensors can cost from tens to thousands of dollars (see hamamatsu S7030/S7031 CCD).
To measure absorbance, a wide spectrum light source is needed (that's why OP's spectrometer has tungsten halogen and deuterium arc). The sun, in some extent, also works for that.
To measure emission, you don't need a light source.
The difficult part is doing the calibration. That can be done with neon light, mercury vapor, etc.
> Strobe pulse is 5us wide (200Khz) so for reliable sniffing I should read I/O ports at 1Mhz. The best I could do was reading necessary 13 channels at 80Khz.
You don't need general protocol decoder, you need to wait for strobe and capture a byte. And you don't need all 13 lines - most firmwares use same byte sequence for each frame, so you can detect frame start and just count the bytes. A main loop may do:
- Wait for frame start
- Capture a frame worth of data - this is 8192 pixels, which is 1024 bytes, which is a half of total RAM
- Slowly send data over serial.. You will miss a couple of video frames, but this is OK, the picture is mostly static.
And you don't even need assembly - the strobe is 80 cycles long, and it looks data comes every 100uS or so - that's 1500+ cycles! Super slow, even inefficient C program can handle it.
This is why the phrase "right tool for the job" exists. As another comment here points out, the MCU in an Arduino is perfectly capable of it, but the software seems to be ridiculously inefficient.
That said, a better device for interfacing this to a PC would probably be the FX2/LP which is commonly found in cheap logic analysers --- it's not clear whether this was actually the type of logic analyser he used originally, but makes perfect sense given its capabilities.