Sciencemadness Discussion Board
Not logged in [Login ]
Go To Bottom

Printable Version  
 Pages:  1  ..  3    5    7  ..  10
Author: Subject: Cheap, Low-Resolution, Raman Spectroscopy
aga
Forum Drunkard
*****




Posts: 7030
Registered: 25-3-2014
Member Is Offline


[*] posted on 25-2-2015 at 15:37


The Biggie still seems to be the way to remove the excitation laser wavelength.

Notch filters seem terribly expensive still.




View user's profile View All Posts By User
m1tanker78
International Hazard
*****




Posts: 685
Registered: 5-1-2011
Member Is Offline

Mood: No Mood

[*] posted on 25-2-2015 at 17:19


Correct me if I'm wrong: Inherent in those ultra sharp cutoff notch/edge filters is the necessity to have tight control of temperature and power supply. I believe the slightest nudge on either would cause the laser line to 'wander' and either pass the filter or cause the filter to block the very low wavenumber peaks. Seems that winging it with such a filter would become an endless game of screwing around with the filter AOI to place the laser line just inside the blocking region.

By using less than ideal optics, the concept is "how low can I go" (in wavenumber, that is). Then it's back to the drawing board of improvement. It's a formidable challenge but I also believe that in the near future these systems will be integrated onto a chip or somehow packaged in a clever way that takes all of the 'fun' out of building these things. :D

BTW John Green, I get a blank page on the link you posted.




Chemical CURIOSITY KILLED THE CATalyst.
View user's profile View All Posts By User
John Green
Harmless
*




Posts: 14
Registered: 4-2-2015
Member Is Offline

Mood: No Mood

[*] posted on 25-2-2015 at 20:57


Sorry tanker, don't know what happened.
Try again.
http://www.opticsinfobase.org/view_article.cfm?gotourl=http%...

Seems to work now but.
PDF attached also.

Attachment: Freshnel Spectrometer oe-18-23-23529.pdf (1MB)
This file has been downloaded 815 times

[Edited on 26-2-2015 by John Green]
View user's profile View All Posts By User
John Green
Harmless
*




Posts: 14
Registered: 4-2-2015
Member Is Offline

Mood: No Mood

[*] posted on 25-2-2015 at 21:24


Some people have suggested simply blocking the laser portion of the spectrum at the ccd with a thin strip of opaque black material. If one is only interested in stokes lines one could shift the laser line off the ccd (or at lease to the higher end) and use a beam stop. I have never tried any of this so I can't vouch for it.

I am going to order one of those Science Surplus spectrometers so if anyone has any pertinent advice please let me know.
View user's profile View All Posts By User
Metacelsus
International Hazard
*****




Posts: 2430
Registered: 26-12-2012
Location: Boston, MA
Member Is Offline

Mood: Double, double, toil and trouble

[*] posted on 26-2-2015 at 08:05


Yes, it should be possible to block the laser wavelength with an opaque object after it goes through the diffraction grating. If that's the case, then I wonder why more people haven't been using it.



As below, so above.
View user's profile View All Posts By User
John Green
Harmless
*




Posts: 14
Registered: 4-2-2015
Member Is Offline

Mood: No Mood

[*] posted on 26-2-2015 at 08:14


Yup that's why the qualifying statement. "I have never tried any of this so I can't vouch for it."
View user's profile View All Posts By User
aga
Forum Drunkard
*****




Posts: 7030
Registered: 25-3-2014
Member Is Offline


[*] posted on 26-2-2015 at 13:11


In my meagre experiments i found that trying to diffract the returning light, and 'simply' block the laser wavelength with an opaque strip was impossible, simply due to the sheer intensity : the green laser light was everywhere.

Clearly my experiments were all a bit silly, and not done under anywhere near ideal conditions, yet the fact remains that even a 0.001% (random guess ...) leakage of the raw reflected laser source into any part of the apparatus causes green-lit mayhem.

Edit:

The Best i got was by using a Lens focused on the Target.

The laser behind the lens was offset by 90 degrees, and hit a small shard of mirror deflected it through the exact (haha) centre of the lens before striking the target.

The idea was to try to excite the target, yet exclude as much of the returning laser light as possible.

The result was also green mayhem.

[Edited on 26-2-2015 by aga]




View user's profile View All Posts By User
John Green
Harmless
*




Posts: 14
Registered: 4-2-2015
Member Is Offline

Mood: No Mood

[*] posted on 26-2-2015 at 14:58


Interesting experiment aga. Perhaps that coupled with one of the cheaper edge filters or even all three schemes filters might work?
View user's profile View All Posts By User
m1tanker78
International Hazard
*****




Posts: 685
Registered: 5-1-2011
Member Is Offline

Mood: No Mood

[*] posted on 26-2-2015 at 17:37


I had decent results in my own meager experiments by using a prism at one end of my garage, directing the beam toward the other end, physically blocking the laser line with a black opaque object, reflecting the remaining diverging light toward the other end of the garage and viewing through a filter. I later modified it to use the same prism as a triple refractor. I would have masochistically included more stages in the same prism but its physical size became a limiting factor for diverging beams of light.

{Laser beam -> air/prism/air -> double reflector}x3

It wasn't a Raman setup, I was trying to get a better handle on some funky green emission from a red laser. The longer light path allowed the beams to diverge quite a lot. The only filter I had on hand at the time was a colored solution in a cuvette. How's that for meager? :D

Putting a laser line barrier on the detector is definitely on my curiosity bucket list. There will be a lot of noise but at least it should work to keep the detector from saturating so quickly.




Chemical CURIOSITY KILLED THE CATalyst.
View user's profile View All Posts By User
m1tanker78
International Hazard
*****




Posts: 685
Registered: 5-1-2011
Member Is Offline

Mood: No Mood

[*] posted on 6-3-2015 at 11:36


I finally got some time to code the pulse generation modules for the CCD. Note that the first is only a functional test bench simulation so the time scale is way off. Also note that for the purpose of verification, the number of readout pulses is truncated to 34 to match the datasheet. Everything is parameterized so it can easily be changed.

Simulation:


Silicon (pulled from SignalTap instance):


The datasheet for the TCD1705D sensor leaves a few unanswered questions. First of all, the events (I'll call them header and footer) that correspond to the SH pulses are not equal. As I understand, the normal mode of operation for these sensors is to capture (integrate) and simultaneously shift out the previous frame pixel by pixel. Why, then, is the header different from the footer (see above images and/or datasheet)?

I may eventually scrap this sensor in favor of one with higher sensitivity and lower resolution. However, if I can get around the lower sensitivity with longer integration times and not too much added noise, I may consider it a keeper.

[Edited on 3-7-2015 by m1tanker78]




Chemical CURIOSITY KILLED THE CATalyst.
View user's profile View All Posts By User
m1tanker78
International Hazard
*****




Posts: 685
Registered: 5-1-2011
Member Is Offline

Mood: No Mood

[*] posted on 9-3-2015 at 19:41





Can anyone entertain a guess as to why there appears to be a missing pair of pulses on the data sheet -- compare RS and CP in the highlighted areas in the image. The header (left) has RS/CP pair inside of phase 1 clock high period. Conversely, the footer (right) has them outside, the same as a regular readout cycle. I've written the code to mimic this but have no idea why or if it even matters. During readout, RS and CP only transition high while the phase 1 clock is low. If RS and CP enter a high impedance state while phase 1 is high then these can be omitted during the header/footer cycle??

I was confused about the 'RS/CP period' annotation (bottom) but was able to sort that out. RS and CP MUST remain low during SH[high] period and there must be a minimum of 200ns padding time between the same.

While I wait for some additional components to be delivered, I'm scratching my head and trying to make sense of either the data sheet's or my own shortcomings. References for this device on the net are almost non-existent, unfortunately! Brute-forcing and verifying will make it work but it won't bring me any closer to understanding why it works.. :mad:




Chemical CURIOSITY KILLED THE CATalyst.
View user's profile View All Posts By User
aga
Forum Drunkard
*****




Posts: 7030
Registered: 25-3-2014
Member Is Offline


[*] posted on 11-3-2015 at 12:57


The stuff on the Right is probably meant to mirror that on the Left, showing the end of one scan cycle and the start of the next, but doesn't.

Likely it is an ignorable error in the datasheet : they just wanted to show the timing for One complete scan.

Do you have a link to the datasheet ?

[Edited on 11-3-2015 by aga]

[Edited on 11-3-2015 by aga]




View user's profile View All Posts By User
m1tanker78
International Hazard
*****




Posts: 685
Registered: 5-1-2011
Member Is Offline

Mood: No Mood

[*] posted on 11-3-2015 at 16:54


Quote: Originally posted by aga  

Do you have a link to the datasheet ?



TCD1705D Datasheet

The scan/readout should be cyclic but the timing diagram begs to differ. Or, as you say, maybe a careless mistake.




Chemical CURIOSITY KILLED THE CATalyst.
View user's profile View All Posts By User
Marvin
International Hazard
*****




Posts: 994
Registered: 13-10-2002
Member Is Offline

Mood: No Mood

[*] posted on 12-3-2015 at 10:15


I can't see the mistake. They look the same to me.
View user's profile View All Posts By User
aga
Forum Drunkard
*****




Posts: 7030
Registered: 25-3-2014
Member Is Offline


[*] posted on 12-3-2015 at 13:00


Thanks for the datasheet.

It's a bit scanty isn't it ? No commentary or even app notes.

It looks very much like Interest in drawing the timing diagrams ended just after the Test outputs.

Even the timing break symbols stop lining up after that.

It's an error is all, and you should rely only on the Left hand side timings.

@Marvin: look closer. m1tanker78 spotted something nobody would ever have even looked for.



[Edited on 12-3-2015 by aga]




View user's profile View All Posts By User
m1tanker78
International Hazard
*****




Posts: 685
Registered: 5-1-2011
Member Is Offline

Mood: No Mood

[*] posted on 29-4-2015 at 20:11


I finally managed to destroy the Toshiba TCD1705D sensor I was experimenting with. I was wiring up and testing a new bus voltage level converter (late at night, half asleep). I somehow connected the low voltage inputs of the sensor to the 15V rail and the sensor died. Thank God the FPGA wasn't connected else it surely would have blown the outputs.

I originally wrote and integrated the HDL to pull the pixel data with a cheap 8-bit serial ADC. The ADC worked well but I had to slow the sensor integration/readout clock down to a crawl in order to stay within the ADC timing specs. The sensor would pretty much saturate if it wasn't light-tight. In other words, the ADC was a burdensome limiting factor but served well enough to test the sensor and my HDL routines which have grown a bit monstrous. Actually, I coded the entire project to be highly portable and offer down to ~5nS event resolution if needed.

I took a little bit of an excursion and implemented a delta-sigma ADC in which the operating parameters can quickly and easily be changed as needed. I can instantiate as many D-S modulators as needed for e.g., sampling the two pixel outputs of the TCD1705D (well, no longer), temperature measurements, and generally any other analog signal/sensor.

My next step will be to implement flexible digital signal processing block(s) on-chip in order to keep the PC overhead as low as possible (maximum portability). I also need to make better use of hard RAM blocks in due time.

I'm thinking about buying a pair of TCD1304AP sensors. It seems the driving circuitry is much simpler and I may get away with directly driving it with LVTTL/LVCMOS levels straight from the FPGA. I'm dreading the long shipping time from overseas which is why I will order at least two of whatever I decide to order.

At the moment, I'm offloading the data to the PC with a USB-to-JTAG converter. I pull every Nth set of samples and do some crude averaging. After I'm done implementing the DSP, I'm going to move on to implementing a high speed USB interface to the PC. At the same time, I'll be writing code to collect and display the data as well as control the operating parameters on the FPGA. An AGC (automatic gain control) is also in the works.

This is probably boring stuff to most of you but that's where the rubber meets the road on my spare time working on this project right now. All optics and lasers are boxed up out of sight to avoid temptation to tinker before the electronics are done. As I mentioned before, I'm approaching this project sort of backwards -- beginning with the sensor, electronics and PC communication then building everything else around it.




Chemical CURIOSITY KILLED THE CATalyst.
View user's profile View All Posts By User
m1tanker78
International Hazard
*****




Posts: 685
Registered: 5-1-2011
Member Is Offline

Mood: No Mood

[*] posted on 21-5-2015 at 06:22


My new TCD1304AP sensors arrived yesterday and I had the opportunity to do some quick testing on the hardware. I plugged one into a solderless breadboard and wired it up. I know this'll make an engineer cringe but what the heck...



Here's the 'test fixture'. In case you're wondering, that's a stack of post-its partially covering the sensor. For the life of me I couldn't find anything small, black, opaque, non-metallic and flat!



Again, using SignalTap to read out the frames. This frame corresponds to the post-it test fixture after tweaking the integration time.



Expanded view of the illuminated area.



Zoomed-in view of the first dummy outputs. Note that there's a mismatch between the indexing of my RAM address and the way the datasheet portrays the signal outputs.

0 to +14 = true dummy outputs. -- Really should be -1 to +14
+14 to +27 = light shield outputs.
+27 to +30 = partially sensitive(?) transition dummy outputs.


These signals are important if one wants to establish a baseline (and one does!). There are a few other factors which can be calculated with this data as well.

I'm about 3/4 done with creating an Ethernet transceiver to communicate with the PC/laptop. There's a bug with the module that calculates the CRC of the outgoing packets. I verified this with Wireshark since I don't yet have a front end application written. I originally wanted to implement a USB interface but IEEE 802.3 fits this project nicely IMO.

[Edited on 5-21-2015 by m1tanker78]




Chemical CURIOSITY KILLED THE CATalyst.
View user's profile View All Posts By User
smaerd
International Hazard
*****




Posts: 1262
Registered: 23-1-2010
Member Is Offline

Mood: hmm...

[*] posted on 21-5-2015 at 08:58


M1Tanker I don't think you're building it backwards. That's been half of the battle for my projects. Without communication who cares how the optics are aligned there's no way to debug anything! People in industry probably have really nice tools and in-house methods for testing their optics but as amateurs we gotta go from the ground up.

Yayy another Raman thread kicking up :)




View user's profile View All Posts By User
aga
Forum Drunkard
*****




Posts: 7030
Registered: 25-3-2014
Member Is Offline


[*] posted on 21-5-2015 at 10:02


Here's my set of check summing routines for ip/tcp/udp/icmp


Attachment: inetcsum.c (4kB)
This file has been downloaded 481 times





View user's profile View All Posts By User
Metacelsus
International Hazard
*****




Posts: 2430
Registered: 26-12-2012
Location: Boston, MA
Member Is Offline

Mood: Double, double, toil and trouble

[*] posted on 21-5-2015 at 12:33


Quote: Originally posted by m1tanker78  
Here's the 'test fixture'. In case you're wondering, that's a stack of post-its partially covering the sensor. For the life of me I couldn't find anything small, black, opaque, non-metallic and flat!


Have you tried electrical tape? (not putting the adhesive side on the glass, of course) It works fine for me.




As below, so above.
View user's profile View All Posts By User
m1tanker78
International Hazard
*****




Posts: 685
Registered: 5-1-2011
Member Is Offline

Mood: No Mood

[*] posted on 22-5-2015 at 05:55



Quote:
Here's my set of check summing routines for ip/tcp/udp/icmp

Thanks aga! I failed to complement the checksum bits and so the frame check bytes were way off. Now, Wireshark reports good packets but strangely I get nothing when I bind a socket to the same port.

Quote:
Have you tried electrical tape? (not putting the adhesive side on the glass, of course) It works fine for me.

I did. It tends to curl up slightly and cause distortion. What I didn't try was sticking 2 pieces of tape together.... or a comb!




Chemical CURIOSITY KILLED THE CATalyst.
View user's profile View All Posts By User
aga
Forum Drunkard
*****




Posts: 7030
Registered: 25-3-2014
Member Is Offline


[*] posted on 22-5-2015 at 10:54


Quote: Originally posted by m1tanker78  
good packets but strangely I get nothing when I bind a socket to the same port.

You mean the receiving code doesn't come back with any data when you try a read() on your socket ?

If the IP address dunt match that of the interface, it won't, unless you set promiscuous mode (ifconfig eth0 promisc)

Also make sure you open the port with protocol = ANY or DGRAM to receive UDP packets (if that's what you're using).

If you're using libpcap, syntax is different.




View user's profile View All Posts By User
m1tanker78
International Hazard
*****




Posts: 685
Registered: 5-1-2011
Member Is Offline

Mood: No Mood

[*] posted on 22-5-2015 at 12:20


Quote: Originally posted by aga  
Quote: Originally posted by m1tanker78  
good packets but strangely I get nothing when I bind a socket to the same port.

You mean the receiving code doesn't come back with any data when you try a read() on your socket ?

If the IP address dunt match that of the interface, it won't, unless you set promiscuous mode (ifconfig eth0 promisc)

Also make sure you open the port with protocol = ANY or DGRAM to receive UDP packets (if that's what you're using).

If you're using libpcap, syntax is different.


Correct. My logic board connects to a router which in turn connects to the PC. On the PC side, I'm using Python on Windows to bind to the same port I set in logic and Wireshark correctly reports. The logic constructs the packets with my PC's IP address and physical MAC (checked with ipconfig). Is this the way to go?

I can open a terminal and send/receive packets to/from the Python script (over 'localhost'). I'll try changing to promiscuous mode and report back.




Chemical CURIOSITY KILLED THE CATalyst.
View user's profile View All Posts By User
aga
Forum Drunkard
*****




Posts: 7030
Registered: 25-3-2014
Member Is Offline


[*] posted on 22-5-2015 at 12:26


If Wireshark on the windows machine sees the packets, then it's a fundamental error in how you're using the libs in your windoze code.

I suspect libpcap (aka WinPcap) would be the easiest way, as (i think) wireshark does the same.

Personally i have never done any comms coding on a windows platform, only ever linux.

Edit:

a quick look at WinPcap says it;s free, and you get WinDump as well ( same as tcpdump) which is really easy way to test.

[Edited on 22-5-2015 by aga]




View user's profile View All Posts By User
aga
Forum Drunkard
*****




Posts: 7030
Registered: 25-3-2014
Member Is Offline


[*] posted on 22-5-2015 at 12:37


Quote: Originally posted by m1tanker78  
Correct. My logic board connects to a router which in turn connects to the PC. On the PC side ... The logic constructs the packets with my PC's IP address and physical MAC ... Is this the way to go?

That'd confuse the router a bit.

Construct the packet with the MAC of the router's port for the Ethernet header, and the PC's IP in the IP header.

Ethernet is only for physically connected devices, so the src & dst MACs must therefore be the MACs of the ports that have a wire between them.

As your PC is not directly connected to your logic board, you need to send the packet to the router, for onwards transmission, which means at the MAC level, your logic board needs to send it to the router's MAC.

The router then figures out from the IP header that the packet is for onwards transmission, and sends it off to the PC (after working out the correct MAC etc).

I am presuming that it is a true Router and has no Switch ports configured (many wifi routers have a built-in switch as well).


[Edited on 22-5-2015 by aga]




View user's profile View All Posts By User
 Pages:  1  ..  3    5    7  ..  10

  Go To Top