Pages:
1
..
3
4
5
6
7
..
10 |
aga
Forum Drunkard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 7030
Registered: 25-3-2014
Member Is Offline
|
|
The Biggie still seems to be the way to remove the excitation laser wavelength.
Notch filters seem terribly expensive still.
|
|
m1tanker78
National Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 685
Registered: 5-1-2011
Member Is Offline
Mood: No Mood
|
|
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](./images/smilies/biggrin.gif)
BTW John Green, I get a blank page on the link you posted.
Chemical CURIOSITY KILLED THE CATalyst.
|
|
John Green
Harmless
Posts: 14
Registered: 4-2-2015
Member Is Offline
Mood: No Mood
|
|
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 1160 times
[Edited on 26-2-2015 by John Green]
|
|
John Green
Harmless
Posts: 14
Registered: 4-2-2015
Member Is Offline
Mood: No Mood
|
|
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.
|
|
Metacelsus
International Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 2531
Registered: 26-12-2012
Location: Boston, MA
Member Is Offline
Mood: Double, double, toil and trouble
|
|
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.
|
|
John Green
Harmless
Posts: 14
Registered: 4-2-2015
Member Is Offline
Mood: No Mood
|
|
Yup that's why the qualifying statement. "I have never tried any of this so I can't vouch for it."
|
|
aga
Forum Drunkard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 7030
Registered: 25-3-2014
Member Is Offline
|
|
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]
|
|
John Green
Harmless
Posts: 14
Registered: 4-2-2015
Member Is Offline
Mood: No Mood
|
|
Interesting experiment aga. Perhaps that coupled with one of the cheaper edge filters or even all three schemes filters might work?
|
|
m1tanker78
National Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 685
Registered: 5-1-2011
Member Is Offline
Mood: No Mood
|
|
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](./images/smilies/biggrin.gif)
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.
|
|
m1tanker78
National Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 685
Registered: 5-1-2011
Member Is Offline
Mood: No Mood
|
|
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:
![](https://lh4.googleusercontent.com/-UZbPhRUTqBY/VPnxwJTqjbI/AAAAAAAAA08/jW4sAxTt7qg/s640/wave2.jpg)
Silicon (pulled from SignalTap instance):
![](https://lh4.googleusercontent.com/-bEuNFJsxzYM/VPnxuD7qtVI/AAAAAAAAA00/W-WRu9SNtf0/s640/wave.png)
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.
|
|
m1tanker78
National Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 685
Registered: 5-1-2011
Member Is Offline
Mood: No Mood
|
|
![](https://lh5.googleusercontent.com/-VmUWjHKrAhs/VP5Tvfd1ImI/AAAAAAAAA1U/fv2eK8Bo8lQ/s800/Datasheet%2520Timing%2520Chart%2520Discrepancy.png)
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..
Chemical CURIOSITY KILLED THE CATalyst.
|
|
aga
Forum Drunkard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 7030
Registered: 25-3-2014
Member Is Offline
|
|
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]
|
|
m1tanker78
National Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 685
Registered: 5-1-2011
Member Is Offline
Mood: No Mood
|
|
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.
|
|
Marvin
National Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 995
Registered: 13-10-2002
Member Is Offline
Mood: No Mood
|
|
I can't see the mistake. They look the same to me.
|
|
aga
Forum Drunkard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 7030
Registered: 25-3-2014
Member Is Offline
|
|
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]
|
|
m1tanker78
National Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 685
Registered: 5-1-2011
Member Is Offline
Mood: No Mood
|
|
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.
|
|
m1tanker78
National Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 685
Registered: 5-1-2011
Member Is Offline
Mood: No Mood
|
|
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...
![](https://lh3.googleusercontent.com/-ZtJjX6uG6cs/VV00I_U77xI/AAAAAAAAA2g/A7o8bsTqjXo/s288/20150520_200750.jpg)
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!
![](https://lh3.googleusercontent.com/-1E8SU7Nr3mU/VV0zYqBwSwI/AAAAAAAAA2M/m9QFD6MX2dU/s800/ccd_st0.png)
Again, using SignalTap to read out the frames. This frame corresponds to the post-it test fixture after tweaking the integration
time.
![](https://lh3.googleusercontent.com/-priEi_sUcl4/VV3WyolB-rI/AAAAAAAAA3w/nrHTkRbJynI/s800/ccd_st3.png)
Expanded view of the illuminated area.
![](https://lh3.googleusercontent.com/-oG5I5d5dW04/VV3TyC8uTrI/AAAAAAAAA3Y/NzvwJLLS6nU/s800/ccd_st2.png)
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.
|
|
smaerd
International Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 1262
Registered: 23-1-2010
Member Is Offline
Mood: hmm...
|
|
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
|
|
aga
Forum Drunkard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 7030
Registered: 25-3-2014
Member Is Offline
|
|
Here's my set of check summing routines for ip/tcp/udp/icmp
Attachment: inetcsum.c (4kB) This file has been downloaded 729 times
|
|
Metacelsus
International Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 2531
Registered: 26-12-2012
Location: Boston, MA
Member Is Offline
Mood: Double, double, toil and trouble
|
|
Quote: Originally posted by m1tanker78 ![](images/xpblue/lastpost.gif) | 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.
|
|
m1tanker78
National Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 685
Registered: 5-1-2011
Member Is Offline
Mood: No Mood
|
|
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.
|
|
aga
Forum Drunkard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 7030
Registered: 25-3-2014
Member Is Offline
|
|
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.
|
|
m1tanker78
National Hazard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 685
Registered: 5-1-2011
Member Is Offline
Mood: No Mood
|
|
Quote: Originally posted by aga ![](images/xpblue/lastpost.gif) |
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.
|
|
aga
Forum Drunkard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 7030
Registered: 25-3-2014
Member Is Offline
|
|
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]
|
|
aga
Forum Drunkard
![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif) ![*](images/xpblue/star.gif)
Posts: 7030
Registered: 25-3-2014
Member Is Offline
|
|
Quote: Originally posted by m1tanker78 ![](images/xpblue/lastpost.gif) | 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]
|
|
Pages:
1
..
3
4
5
6
7
..
10 |