https://en.m.wikipedia.org/wiki/Spectrophotometry
I guess it never occurred to me that machines doing light-spectrum-analysis of some sample might do it in various different ways, and therefore, may in fact be different machines and therefore have different names. Or something.
I decided to do some looking-into terms used on this thing, like the "[wavelength?] slew rate" and came across the term: Spectrophotometry.
It's pretty much how I imagined, I just thought it was a "Spectrum Analyzer". I guess the difference is that other methods might, say, turn the sample into plasma, to see what colors it *emits*, whereas, I think this machine is more about seeing what colors the sample *reflects* (or *transmits*). It's more of a passive measurement, in terms of the sample.
Actually, though, this is probably more along the lines of the sorta thing I'd actually find uses for. E.G. I had a weird LED which I'm near-certain glows blue when fully-powered, but more of a teal when the power supply is removed and the capacitor discharges. I don't want to plasmatize anything, here, just see if the spectrum changes.
AND this would be *far* simpler to make hardware for. The Applied Science guy had such a machine with, simply, a piece of fiber-optic he'd point at various samples. Sure, if you run the machine once, pointing at white paper, then run it again pointing at the LED, it's basically calibrated-enough to see *changes* in peak wavelengths. Not like I need to know exact luminous-flux values, or even exact wavelengths, or something.
So, again, I'm ponderng actually figuring out how to use this thing as it was intended. Hah!
Again, the hardware isn't *that* complicated...
(no linky wikipedia imagery?)
The fiber optic would point at the object/sample. The other end points at a prism, or diffraction-grating (aka "monochrometer," thus the "MONO" port on the back). The photodiode on the other side of the prism is moved-around within the rainbow at its output, to see a small window of the different colors. An aperture might be useful on the photodiode to focus on a smaller range of wavelengths, and also in case the light source is too dim/bright...
I mean, yeah, it could definitely be doable.
Reality sets in, a bit, I guess... The SD70 doesn't do the actual measurements; as far as I can tell, it just moves the photo-sensor/prism.
So that means we need an analog circuit for the photodiode, and maybe aperture control, and an A/D converter, and some way to communicate its readings (e.g. to a computer)... at which point we're talking a microcontroller. At which point we could just program a few more GPIOs to move the prism (or photodiode). At which point we could put a linear CCD on the prism... Heh. Haven't I been here before?
Part of me wants to use this thing as it was intended, though. So, I dunno. Maybe I'll add a toggle-switch between its ROM's Chip-Select and whatever custom firmware we might come up with.
...
On that note, we discovered a function-call that calls a function's address loaded/stored in RAM... A function-pointer. Which, I suppose, in the interest of hackery, could make for a way to boot off the original ROM, then bounce off into another/custom program. It'd be a hack, and I can't quite visualize its being any easier than just toggling that chip-select.
But, that thought-process brought up a thunk I hadn't thunk: What about a custom (boot) ROM which accesses functions in the original? Like what? Well, e.g. the init-code is just a bunch of grunt-work which could easily be mis-copied... Have you ever tried to get an HD44780-compatible LCD running? Oh, sure it looks simple enough, just load those register... but I've run into modules whose init-sequence had to be in exactly the right order (despite the registers being loaded with the same values either way!). Or, e.g. the RS-232 initialization, which also requires the CTC... Heh, or that front panel! Matrix scanning... And, it looks like there's already a serial put-string function just waiting to be called... Heh!
Starting to sound pretty nice just moving the original ROM to 0x4000, and having all that accessible!
This idea, probably, is quite obvious to others, but it took me some time to come to. Heh!
Oh, hmm, maybe it uses absolute jumps/calls..
OK, so leave it at 0x0000, new ROM at 0x4000, and... change the first instruction in to original to jump straight to the new ROM... Eah, I kinda don't like that, burning a new/barely-modified ROM to *replace* the original... (why not? would prb help to preserve the original, too). I might. Otherwise, maybe I could think of something along the lines of paging. I dunno.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.