How much current will it produce in the dark? Depends. For a photodiode in photovoltaic mode (no bias), I would think effectively none (ignoring possible really small quantum effects, about which I know nothing). For the same photodiode in photoconductive mode (reversed biased), the dark current depends on the bias and the temperature. Since you're using the LED as a photodiode, I would expect at least generally similar behavior from the LED. Just like other photodetectors, for lowest noise and dark current, cool it. IIRC, cooling by 7 K reduces dark current by roughly half.
Dark current does not depend on gamma rays or other external events, only on the energy of electrons in the semiconductor which is temperature dependent. Not saying you can't detect high-energy photons, just that you'll get dark current without them. The colder you make it, the less dark current you'll have.
I can't say much about performance, except to have some qualms about the USB port power, which might be kinda noisy.
I should have been a bit more specific. My uncooled LED is covered with black cloth to exclude room light as far as is practically possible but it would still be seeing IR as the black body curve at ~ 300K IIRC peaks at around 10 microns
I’ve just completed some lab experiments using the Propeller and I’d like to pose a few questions that pertain to its application in an instrument for detecting light.
Optical detectors such as photomultiplier tubes and photodiodes produce small currents. Less well known is the fact that LED’s can also be used as optical detectors.
I’m currently documenting a USB-enabled, P1+LV-based instrument that measures and logs very small currents and voltages. My instrument allows direct connection of a large number of sensors - with all necessary data acquisition circuitry on-board.
The tests I’m carrying out at the moment are using a water clear 5mm LED (in this case a turquoise green emitter), using the instrument to measure the photocurrent produced by this LED under illumination.
Questions :
How tiny a current/voltage do you think it might be possible to measure with a low cost, Propeller-based instrument ? The instrument is to draw its power from a laptop’s USB port and I’m interested in demonstrated, not theoretical performance.
What current would my LED detector produce in the dark, and then under ambient room light conditions, and how much noise would one expect in these measurements ?
If one were to shine red, and then blue light from LED’s onto this detector, what response(s) might we expect ?
Before spilling the beans, I’d be curious to hear the thoughts of others !
This instrumentation project is really nicely suited to use of a P1 Propeller and the results I think are quite remarkable. I hope be in a position to post some data (that will answer the above questions) and more technical information about this instrument in the coming week.
Richard
Richard, have you taken a look at some of the low cost imaging chips that are used for cameras and linear arrays used for bar code scanners that are available. The costs are reasonable and the output signal is often amplified and buffered on the chip. Something designed for light detection may be the way to go rather than trying to adapt leds designed for emitting light.
This seems to be the way more and more spectroscopy instruments are going.
funny you should mention that ! As you point out, linear CCD's are used in document and bar code scanners and are dirt cheap ! And area array sensors are found in digital cameras and are heavily used in astronomical imaging.
Combine a linear CCD with a slit, and diffraction grating (could be either in transmission or reflection mode) and presto - you have yourself an el cheapo spectrometer ! The other thing you will find useful is a correlated double sampling chip like the Analog Devices AD9826 - this measures and digitizes the difference between video and reset levels as individual charge packets are clocked from the CCD's shift register and pass through the CCD's output amplifier.
For work in the visible/near IR regions (say 400-1000 nm) the cheap sensors work great but UV sensitive image sensors that can go down to 200 nm tend to be much more expensive.
BTW EBay is a great place to find some of the aforementioned items (for example, I grabbed some high quality concave gratings recently for only ~$40 each - new would have been $500 approx - and a small piece of transmission grating film can be had for cents).
But I'm getting way, way ahead of myself here - just lets say there are several different Propeller spectrometers just like this already - but I'd better save a few surprises for my website launch !
My earlier remarks/questions about the LED's were not necessarily based on planning to use them for spectroscopy, more an example of thinking about their spectral response and also measuring small currents with a Prop.
How tiny a current/voltage do you think it might be possible to measure with a low cost, Propeller-based instrument ? The instrument is to draw its power from a laptop’s USB port and I’m interested in demonstrated, not theoretical performance.
What current would my LED detector produce in the dark, and then under ambient room light conditions, and how much noise would one expect in these measurements ?
If one were to shine red, and then blue light from LED’s onto this detector, what response(s) might we expect ?
Well at the ultimate limit of sensitivity I've used ~$30 in parts to achieve a 30 fempto-amp noise floor with a BPW34 and 53Hz bandwidth. On the other end, I've gotten to ~2GHz bandwidth and ~6uA noise floor using a ThorLabs FDS025. Photo-diode amplifiers are tricky and not often talked about. Generally they also perform best when built right next to the detector and specific to each application's needs. That said, getting 1Mohm gain and 1MHz bandwidth with a diode like the BPW34 is an awful useful target to aim for.
Usb power just means you need good input filtering and low power consumption. (isolation can be useful as well) I've yet to use even 100mW in a photo-diode amplifier, so that shouldn't be an issue.
LED dark current? With zero bias voltage, dark current is essentially zero. With some bias current I'd guess "relatively high" when compared to photo-diodes of similar size. Also note that LED's are different colors due to the band-gap. Photons of lower energy than the LED's band-gap mostly won't be detected. I.e. shine a red led at a blue led and you should get almost no photo current in the blue led. Shine a blue at a red, and you'll get a photo-current.
Oh putting a black cloth over your LED in a lighted room is not "dark". Plenty of photons will leak through that cloth. Generally need a metal can with no holes to stop all ambient light.
Phillip Hobb's book is a great reference in particular for scientific applications, Building Electro-Optical Systems: Making It All Work. Also his web site http://electrooptical.net/.
For the Propeller, the native sigma-delta work best for AC signals, but it is not so great for DC baseband due to drift of the Propeller threshold, at least for small signals. On the other hand, a source or sink current is a natural for connection to the sigma-delta circuit. The easiest connection to Vss or Vdd leaves it with a reverse bias, but it is also possible to arrange the circuit for zero or adaptive bias.
The simplest circuit to get going is RCtime. I recall being impressed with the response with a green LED, no capacitor at all except for the <10pF of the input pin.
LEDs generally have a small area compared with photodiodes as such, thus a relatively small photocurrent. The relatively high bandgap voltage means that they have low capacitance for high speed response, and they generally have relatively small reverse saturation current. Green LED, bandgap > 2V, down to I0 = 10-20A.
Thanks very much to those who posted responses re the use of an LED as a detector. The last couple of posts in particular have some really great information and zeroed in to the point where now, heres some experimental data that backs up those spot-on opinions.
To perform the first test shown in Fig. 1, a battery-derived (2xNiMH cells) 0-~3V variable source was wired via a 1Gohm series resistor to the current input terminal of my P1-based instrument. Using a DVM I measured the input voltage and the instrument measured the current. A number of replicate readings were made at different set voltages and the results then plotted.
The measured current is pretty much 0-3 nA as expected (n.b. the exact resistance was not known) ; the sds of each of the current readings here are several hundred fA as seen in the attached data table. Data was sampled every 10 msec. In this experiment a crude Faraday shield was used; this consisted of nothing more than a grounded aluminium salad bowl covering the bare PCB and the leads from the battery box/resistor.
The results of test 2 are shown in Fig. 2. This is a screen capture of the LV front panel that controls and acquires data from the instrument.
Here the LED leads are directly connected to ground and the current input terminal (a virtual ground). The PCB is now inside a small Hammond enclosure but the external LEDs leads are exposed (unshielded). The LED is covered in black cloth and is also inside a black cardboard box in a reasonably dark room.
The green trace in the middle of screen is the measured photocurrent (1000 channels here corresponds to approx. 40 s of data acquisition). The vertical scale runs from -30 pA to +100 pA. At right the red trace is an expansion of the green trace scale is now -2 pA to + 6 pA. The blue trace is smoothed data using LVs built-in SG filter from that dataset we derive a mean I of 1.83 pA, with an sd of 0.16 pA. Peak-to-peak noise in the raw dataset looks to be around ~5 pA. I also used the histogram vi in LV to display a histogram of the current readings the yellow bar chart. And a reminder - this is one of the benefits of LV these neat little things come for free (no Im not an employee of National Instruments !).
Being close to having the LED in a zero bias condition, its dark current is to all intents and purposes zero, as quite a number of forumistas have commented.
In my final experiment the LED (remember it was a turquoise emitter when in that mode) is exposed to ambient (now normal room light), then a blue LED and then a red LED. The data is shown in Fig. 3, after exporting into Origin. Here the red and blue traces are the detector currents using the respective illuminating LEDs, while the ambient dataset is the black trace it is indistinguishable from/underneath the red one.
Exposure to light from the blue LED (positioned here some 40 cm from the detector) results in a current of 13.4 nA, while placing the red LED just a few mm from the detector registers nothing. Yes, it is all about the size of the LED band gap photon energies increase in the series ROYGBIV and light at longer wavelengths i.e. lower photon energies (than the detector LED would emit) will not elicit any response.
Logging very small currents that one might describe as just a whisper is possible with home-built P1-based instrumentation and one can certainly measure down to a few/few tens of pA. Being a spectroscopist and not an electrical engineer Ive still a lot to learn about this subject. Shielding is extremely important and I forgot to mention, I pulled out the plugpack input to my laptop while doing these experiments. Without doing that I was seeing some serious noise in my traces regular excursions of around 1 nA on a many second timescale.
While this sort of instrumentation could have been based around another processor chip, Ive settled on the Propeller as I find it very easy to use and I now re-use elements of my designs (hardware and software) over and over again in new P1 projects. Back at work now, but hoping to post some more stuff here in the near future for those who might be interested...
Thanks for showing the results. I'm very interested to hear more about the Prop circuit you are using and your instrumentation for spectroscopy as it develops.
Im currently working on a project to demonstrate how Propeller-based instrumentation can be easily controlled from a LabVIEW runtime executable (LV RTE), as mentioned earlier in this thread. My target platform is a Propeller Activity Board, since this will be available to many forum members.
For this initial project l will exercise the ADS124S01 4 channel, 12 bit ADC chip thats the little 10 pin VSSOP package that sits in the bottom right hand corner of the Activity Board below the prototyping area. From our GUI well set the input channel #, the dwell time t (in microseconds) between ADC readings, implement n-samples per point summation averaging to improve S/N at each stored point and store these averaged points (say m of them in total) on-the-fly into a reasonably large data buffer. The total time taken for the full data acquisition will thus be (n*m*t) usec.
At the conclusion of the data capture, well dump the data buffer back to LabVIEW on the PC and display it, along with with a histogram of the readings and some statistics on the data acquired. In addition it will be instructive to look at the noise spectrum of the data, so we will also compute a Fourier transform (FT).
Once we have that up-and-running we can connect an adjustable input voltage to see how well the on-board ADC really performs. The Activity Boards on-board LEDs will indicate what state the instrument is in at any given moment as all this is happening.
After some initial testing this will run in PASM at a maximum single point sampling rate of around 125 kHz, or 8 usec per ADC reading, and there will be sufficient HUB ram to assign a buffer size of around 15800 words deep. Ive attached a screen capture of my LabVIEW vi as it stands at the moment. Here, I just used a battery box and pot to set a DC input level of ~ 2.3 V on ADC channel 2 full scale on a 12 bit ADC gives a digital code of 4095, corresponding to a 5V input.
I still have a little polishing work to do, then Ill generate a distribution .exe and I also want to try it out on a few different PCs/forum members before deeming it ready to make public. Ill also be posting the Propeller code once Ive tidied up my documentation. My time is somewhat limited (pity about that day job ) so please be patient hopefully it will be worth the wait.
If you think you might be interested in this project then you can get prepared by downloading (at no cost) the LabVIEW runtime engine at http://www.ni.com/download/labview-run-time-engine-2013/4059/en/ it is ~213 MB. BTW Ill be building the executable in LabVIEW2013 so do make sure you get this version of the NI run-time engine ! (National Instruments released LV2014 some time ago but I have not yet migrated to this.)
n.b. The .exe I distribute will run on PCs - but probably also on Macs using PC emulation software - although I havent currently tested that.
If this proves to be of interest to forum members Ill consider doing some follow-up projects down the track, but first we need to get the tools in place and lets walk before we run !
As promised, here's a zip file containing both a LV2013 executable and a spin file to run on a Parallax Propeller Activity Board (AB). The executable interacts with the ABs on-board ADC to capture data from and display the ADC readings from an analog input signal that's applied to any one of its 4 channels. (n.b. full scale input = 5V = 4095 (2^12-1))
To use these, you'll need to do the following :
1) First, download and install the LV2013 runtime engine from the NI website (info in the previous posting in this thread). Make sure you get that particular version !!
2) Next, unzip distribution.zip. I had to change the extension on the LV runtime executable to .abc to get gmail to accept the .zip as an attachment (as Ive been emailing it recently). Change that back to .exe when you've unpacked the distribution onto your PC. There are a few other files in that folder - be sure to leave them all in that one place as they are essential for LV to work properly. The spin file can be moved wherever you like.
3) Connect up an AB and launch Activity_Board_v1(230400).spin.
4) Once thats been done, run ActivityBoard_LV2013_ADC_v1.exe - if all is well you should see it load up with the screen grab that I posted earlier. Clicking on the arrows at the top left of screen will launch the executable the single arrow icon means run the vi once, and the circular arrow icon means run the vi continuously. Execution can be ended at any time by clicking on the red stop button.
5) While things are running the yellow LED at DAC0 should come on during ADC activity, and the blue LED adjacent the mini USB connector will indicate data transfers back to the PC.
Notes :
The default settings here assume you have an analog input connected to the channel 2 input on the AB.
The LV build/spin code assumes a baud rate of 230400 for the data transfers. Thats set by a baud rate constant in the .spin file but should not be changed. I've tested this on several PC's here and it works fine at that speed but let me know if you encounter problems. Ive recently had another Prop user get it running on a Mac too, running in emulation mode (thanks Kyle).
You'll find you can edit graph x and y scales and input text fields on-the-fly in the LV screen using standard point and click/text editing methods.
The code is straightforward - no rocket science here. I use a simple serial port monitor/dispatcher running on the AB to respond to various command strings that are issued from LV. Youll find those commands documented in the code. For example, LV sends the string C2, to set the ADC channel # to 2, with the comma being used as a sentinel character.
Note that there are a couple of things in the code that Im currently working on (DAC support, and addition of a TSL235 light-to-frequency converter) - these are not being used by this LV program.
The primary purposes of this project are twofold - to introduce forum members to a very simple method for linking a program running on the Propeller back to LV and secondly, to see how to work with a LV run-time executable. As Ive mentioned previously, that exposes user data (that the Propeller is very good at acquiring) to a host of signal processing, analysis tools and graphics that would otherwise take a large amount of time to develop.
Additional features can of course be very easily be added to make this much more useful (file saving, arbitrary waveform generation etc etc) - which I hope to get to down the track if there is interest.
In the coming weeks Ill be giving top priority to finishing my website, which at the moment I'm finding is taking up most of my spare time. This will have many pages devoted to all kinds of scientific instruments (primarily for chemistry and physics) mainly Propeller, but some XMOS-based projects too. Some you've seen in this thread already, but there are many more.
I'm aiming for this to be a how-to guide that explains what the instruments measure, how they measure it and why thats important, and shows typical experimental results. I also plan to have more to say there about developing LV vis as those details are hidden away in the LV exe.
Thanks for the demo program and the explanation. The instructions were clear, and I was able to run it. The only issue I had was that the LV screen expended beyond my screen & I had to scroll to see the full display. Part of my problem was that I was trying this on a NetBook that has limited screen resolution settings (800x600 and 1024x600).
I don't happen to have an activity board to try it out, but I looked over the project files to see what went into it. Nice job! I was kind of surprised to see that the Prop main code is all in pasm.
About the run-time engine. I see that there is a NI also offers a run-time engine for the Mac and one for Linux. I know nothing about how the run-time executables are built up. Is it very difficult to build them cross-platform?
The runtime executable is created by an Application Builder tool that is part of LabVIEW. After one is satisfied that a vi is working correctly , the .exe is very easily generated (it is accessed by a menu selection in LV). The following link explains the situation w.r.t transportability - whereas vi's are transportable cross-platform that is not the case for the executables.
I checked with National Instruments this morning and and was told that my LV licence could be used on either a Mac or a PC. I actually wasn't aware of that so when I get a chance I'll investigate making a Mac application that would work with a Mac runtime engine.
Yes, my Propeller code is mainly PASM. I really haven't used SPIN that much as I'm more fluent in C, but probably like many old-timers here my first language was Fortran. Back in the early 70's almost all science students in Australia did some programming and I still remember the decks of punched cards that we used to submit at the front desk of the computer centre each night - only to read on the line printer output in the morning "fatal error on line 23" - my how things have changed since then...
I find PASM very easy to code in, the instruction set is flexible (and very good for I/O) and using it delivers good execution speed. I'm certainly no guru but I've learned enough to do a serviceable job. And the basic code here just needs slight modification for each new instrument that I'm working on - both at the PC end and at the Prop end - that's certainly a big bonus for rapid prototyping !
HI Richard, you triggered me to give my 2cent: we also started with FORTRAN on a main frame and we share equal experiences. We had 3 card punches for all the students and only one of them had a working printer to print the characters to the first line. That definitely supported mistyping. ;-) I wonder what todays students will talk about in 40 years about their problems!
very good to chat earlier today - looks like a Melbourne Propeller meet-up is now pencilled in for Monday July 20th. I hope this advance notice might give other Aussies a chance to make it too !
In my instruments, Propeller-based hardware teams up with a LabVIEWTM PC-based front end, giving a high quality GUI. For me, the synergy of those two tools comes close to nirvana for rapid development of easy-to-use scientific instruments rivalling the performance of commercial products but at typically 1/10-1/100 the cost. Thats potentially great news for educators with large teaching labs but small budgets.
That cost excludes the license for LabVIEW right? I'd think academia gets those licenses at deep discounts, but outside of it, LabVIEW isn't exactly cheap.
Yes you are quite right, LabVIEW licenses don't come cheap. I maintain my academic license for my PC, for which there is a 75% discount. Recently I investigated purchasing a separate Mac development environment (with the Application Builder) and was quoted A$1750, so ouch - A$7500 for a full-priced license. (Note that currently 1A$ = US$0.77).
The economics of LabVIEW do make sense in a teaching environment. Consider putting many low cost instruments into a large teaching lab where you have 150 students in a session - with individual experiments being conducted by groups of 2-3 students. You'll need just the 1 development environment to build the runtime executable(s) and then have the free LabVIEW Runtime engine imaged onto each PC. The economy of scale really operates to advantage in this situation.
I find the vast array of tools available in LV also allows one to develop complex instrumentation very quickly, particularly when any signal processing/data analysis is required. But this isn't meant to be a plug for LV, just my own experience with using it.
Some years ago I remember there being a LV student edition. It was indeed a low cost option and IIRC was sold via an arrangement between NI and one of the large publishers, but I'm not sure of the status of this now - could be worth checking out.
thanks for posting that information about the home edition of LabVIEW - very interesting. Lachlan emailed me about this which alerted me to check the forum to see your postings.
I'm on holidays with my family on the Amalfi coast in Italy at the moment but when I get back to Australia in about 3 weeks I'll definitely get a copy and try it out. I am optimistic that it will be a useful tool and certainly the price is attractive. It looks similar to the student edition that we used in the lab a few years ago and that version was quite capable
My last post here was back in June, 2015 and I’ve returned to announce the launch of a new website - www.instruments4chem.com.
My site describes the suite of scientific instruments I've designed and built using both Parallax Propeller and XMOS processors. Over time my site (which has a strong educational focus) has evolved into a detailed record of what I’ve achieved and outlines the how and why.
I‘ve also included comprehensive explanations of the underlying science to provide context, as well as detailed descriptions of experiments/data to demonstrate how well my different instruments perform.
You’ll see that I’ve been working in a number of other areas of possible forum interest too, including FPGA’s, P1V, P2, and HyperRAM - to name a few. Be sure to check out some of the items under the Test+Measurement menu that just didn’t logically fit anywhere else.
I’ve really enjoyed building this website. I’m hoping the instruments and experiments I've described will offer others real insights into how one can undertake scientific investigations on a limited budget using high quality, home-grown instrumentation – enjoy.
You’ll see that I’ve been working in a number of other areas of possible forum interest too, including FPGA’s, P1V, P2, and HyperRAM - to name a few.
Do you have reference code for HyperRAM - even if done for XMOS, it would help P1/P2 coders.
Did you test areas not covered in the data sheet, like do the parts refresh while CS# is high (no clk), or is a clock needed ?
Did you confirm a continual write/read inside the max times, is enough to refresh the used subset of memory ?
Do you need to use the handshake lines, or is timing enough ?
Website looks good. It needs a Title tag so that a bookmark doesn't just try to save it under the name 'Home'. LED's should be spelled LEDs (for plural form).
Didn't notice anything else obviously wrong, but then again I only spent a few seconds. Looked clean and nice though.
Comments
I think you still get occasional gamma ray events
I vaguely remember some small wavelength shift using leds as detectors, can't remember which direction, so lets go with blue light
Dark current does not depend on gamma rays or other external events, only on the energy of electrons in the semiconductor which is temperature dependent. Not saying you can't detect high-energy photons, just that you'll get dark current without them. The colder you make it, the less dark current you'll have.
I can't say much about performance, except to have some qualms about the USB port power, which might be kinda noisy.
The kind of dark that appears to the human eye?
Are leds sensitive to say - infra red?
Dave
Richard
Richard, have you taken a look at some of the low cost imaging chips that are used for cameras and linear arrays used for bar code scanners that are available. The costs are reasonable and the output signal is often amplified and buffered on the chip. Something designed for light detection may be the way to go rather than trying to adapt leds designed for emitting light.
This seems to be the way more and more spectroscopy instruments are going.
funny you should mention that ! As you point out, linear CCD's are used in document and bar code scanners and are dirt cheap ! And area array sensors are found in digital cameras and are heavily used in astronomical imaging.
Combine a linear CCD with a slit, and diffraction grating (could be either in transmission or reflection mode) and presto - you have yourself an el cheapo spectrometer ! The other thing you will find useful is a correlated double sampling chip like the Analog Devices AD9826 - this measures and digitizes the difference between video and reset levels as individual charge packets are clocked from the CCD's shift register and pass through the CCD's output amplifier.
For work in the visible/near IR regions (say 400-1000 nm) the cheap sensors work great but UV sensitive image sensors that can go down to 200 nm tend to be much more expensive.
BTW EBay is a great place to find some of the aforementioned items (for example, I grabbed some high quality concave gratings recently for only ~$40 each - new would have been $500 approx - and a small piece of transmission grating film can be had for cents).
But I'm getting way, way ahead of myself here - just lets say there are several different Propeller spectrometers just like this already - but I'd better save a few surprises for my website launch !
My earlier remarks/questions about the LED's were not necessarily based on planning to use them for spectroscopy, more an example of thinking about their spectral response and also measuring small currents with a Prop.
Richard
Well at the ultimate limit of sensitivity I've used ~$30 in parts to achieve a 30 fempto-amp noise floor with a BPW34 and 53Hz bandwidth. On the other end, I've gotten to ~2GHz bandwidth and ~6uA noise floor using a ThorLabs FDS025. Photo-diode amplifiers are tricky and not often talked about. Generally they also perform best when built right next to the detector and specific to each application's needs. That said, getting 1Mohm gain and 1MHz bandwidth with a diode like the BPW34 is an awful useful target to aim for.
Usb power just means you need good input filtering and low power consumption. (isolation can be useful as well) I've yet to use even 100mW in a photo-diode amplifier, so that shouldn't be an issue.
LED dark current? With zero bias voltage, dark current is essentially zero. With some bias current I'd guess "relatively high" when compared to photo-diodes of similar size. Also note that LED's are different colors due to the band-gap. Photons of lower energy than the LED's band-gap mostly won't be detected. I.e. shine a red led at a blue led and you should get almost no photo current in the blue led. Shine a blue at a red, and you'll get a photo-current.
Oh putting a black cloth over your LED in a lighted room is not "dark". Plenty of photons will leak through that cloth. Generally need a metal can with no holes to stop all ambient light.
Marty
For the Propeller, the native sigma-delta work best for AC signals, but it is not so great for DC baseband due to drift of the Propeller threshold, at least for small signals. On the other hand, a source or sink current is a natural for connection to the sigma-delta circuit. The easiest connection to Vss or Vdd leaves it with a reverse bias, but it is also possible to arrange the circuit for zero or adaptive bias.
The simplest circuit to get going is RCtime. I recall being impressed with the response with a green LED, no capacitor at all except for the <10pF of the input pin.
LEDs generally have a small area compared with photodiodes as such, thus a relatively small photocurrent. The relatively high bandgap voltage means that they have low capacitance for high speed response, and they generally have relatively small reverse saturation current. Green LED, bandgap > 2V, down to I0 = 10-20A.
To perform the first test shown in Fig. 1, a battery-derived (2xNiMH cells) 0-~3V variable source was wired via a 1Gohm series resistor to the current input terminal of my P1-based instrument. Using a DVM I measured the input voltage and the instrument measured the current. A number of replicate readings were made at different set voltages and the results then plotted.
The measured current is pretty much 0-3 nA as expected (n.b. the exact resistance was not known) ; the sds of each of the current readings here are several hundred fA as seen in the attached data table. Data was sampled every 10 msec. In this experiment a crude Faraday shield was used; this consisted of nothing more than a grounded aluminium salad bowl covering the bare PCB and the leads from the battery box/resistor.
The results of test 2 are shown in Fig. 2. This is a screen capture of the LV front panel that controls and acquires data from the instrument.
Here the LED leads are directly connected to ground and the current input terminal (a virtual ground). The PCB is now inside a small Hammond enclosure but the external LEDs leads are exposed (unshielded). The LED is covered in black cloth and is also inside a black cardboard box in a reasonably dark room.
The green trace in the middle of screen is the measured photocurrent (1000 channels here corresponds to approx. 40 s of data acquisition). The vertical scale runs from -30 pA to +100 pA. At right the red trace is an expansion of the green trace scale is now -2 pA to + 6 pA. The blue trace is smoothed data using LVs built-in SG filter from that dataset we derive a mean I of 1.83 pA, with an sd of 0.16 pA. Peak-to-peak noise in the raw dataset looks to be around ~5 pA. I also used the histogram vi in LV to display a histogram of the current readings the yellow bar chart. And a reminder - this is one of the benefits of LV these neat little things come for free (no Im not an employee of National Instruments !).
Being close to having the LED in a zero bias condition, its dark current is to all intents and purposes zero, as quite a number of forumistas have commented.
In my final experiment the LED (remember it was a turquoise emitter when in that mode) is exposed to ambient (now normal room light), then a blue LED and then a red LED. The data is shown in Fig. 3, after exporting into Origin. Here the red and blue traces are the detector currents using the respective illuminating LEDs, while the ambient dataset is the black trace it is indistinguishable from/underneath the red one.
Exposure to light from the blue LED (positioned here some 40 cm from the detector) results in a current of 13.4 nA, while placing the red LED just a few mm from the detector registers nothing. Yes, it is all about the size of the LED band gap photon energies increase in the series ROYGBIV and light at longer wavelengths i.e. lower photon energies (than the detector LED would emit) will not elicit any response.
Logging very small currents that one might describe as just a whisper is possible with home-built P1-based instrumentation and one can certainly measure down to a few/few tens of pA. Being a spectroscopist and not an electrical engineer Ive still a lot to learn about this subject. Shielding is extremely important and I forgot to mention, I pulled out the plugpack input to my laptop while doing these experiments. Without doing that I was seeing some serious noise in my traces regular excursions of around 1 nA on a many second timescale.
While this sort of instrumentation could have been based around another processor chip, Ive settled on the Propeller as I find it very easy to use and I now re-use elements of my designs (hardware and software) over and over again in new P1 projects. Back at work now, but hoping to post some more stuff here in the near future for those who might be interested...
Richard
For this initial project l will exercise the ADS124S01 4 channel, 12 bit ADC chip thats the little 10 pin VSSOP package that sits in the bottom right hand corner of the Activity Board below the prototyping area. From our GUI well set the input channel #, the dwell time t (in microseconds) between ADC readings, implement n-samples per point summation averaging to improve S/N at each stored point and store these averaged points (say m of them in total) on-the-fly into a reasonably large data buffer. The total time taken for the full data acquisition will thus be (n*m*t) usec.
At the conclusion of the data capture, well dump the data buffer back to LabVIEW on the PC and display it, along with with a histogram of the readings and some statistics on the data acquired. In addition it will be instructive to look at the noise spectrum of the data, so we will also compute a Fourier transform (FT).
Once we have that up-and-running we can connect an adjustable input voltage to see how well the on-board ADC really performs. The Activity Boards on-board LEDs will indicate what state the instrument is in at any given moment as all this is happening.
After some initial testing this will run in PASM at a maximum single point sampling rate of around 125 kHz, or 8 usec per ADC reading, and there will be sufficient HUB ram to assign a buffer size of around 15800 words deep. Ive attached a screen capture of my LabVIEW vi as it stands at the moment. Here, I just used a battery box and pot to set a DC input level of ~ 2.3 V on ADC channel 2 full scale on a 12 bit ADC gives a digital code of 4095, corresponding to a 5V input.
I still have a little polishing work to do, then Ill generate a distribution .exe and I also want to try it out on a few different PCs/forum members before deeming it ready to make public. Ill also be posting the Propeller code once Ive tidied up my documentation. My time is somewhat limited (pity about that day job ) so please be patient hopefully it will be worth the wait.
If you think you might be interested in this project then you can get prepared by downloading (at no cost) the LabVIEW runtime engine at http://www.ni.com/download/labview-run-time-engine-2013/4059/en/ it is ~213 MB. BTW Ill be building the executable in LabVIEW2013 so do make sure you get this version of the NI run-time engine ! (National Instruments released LV2014 some time ago but I have not yet migrated to this.)
n.b. The .exe I distribute will run on PCs - but probably also on Macs using PC emulation software - although I havent currently tested that.
If this proves to be of interest to forum members Ill consider doing some follow-up projects down the track, but first we need to get the tools in place and lets walk before we run !
Richard
To use these, you'll need to do the following :
1) First, download and install the LV2013 runtime engine from the NI website (info in the previous posting in this thread). Make sure you get that particular version !!
2) Next, unzip distribution.zip. I had to change the extension on the LV runtime executable to .abc to get gmail to accept the .zip as an attachment (as Ive been emailing it recently). Change that back to .exe when you've unpacked the distribution onto your PC. There are a few other files in that folder - be sure to leave them all in that one place as they are essential for LV to work properly. The spin file can be moved wherever you like.
3) Connect up an AB and launch Activity_Board_v1(230400).spin.
4) Once thats been done, run ActivityBoard_LV2013_ADC_v1.exe - if all is well you should see it load up with the screen grab that I posted earlier. Clicking on the arrows at the top left of screen will launch the executable the single arrow icon means run the vi once, and the circular arrow icon means run the vi continuously. Execution can be ended at any time by clicking on the red stop button.
5) While things are running the yellow LED at DAC0 should come on during ADC activity, and the blue LED adjacent the mini USB connector will indicate data transfers back to the PC.
Notes :
The default settings here assume you have an analog input connected to the channel 2 input on the AB.
The LV build/spin code assumes a baud rate of 230400 for the data transfers. Thats set by a baud rate constant in the .spin file but should not be changed. I've tested this on several PC's here and it works fine at that speed but let me know if you encounter problems. Ive recently had another Prop user get it running on a Mac too, running in emulation mode (thanks Kyle).
You'll find you can edit graph x and y scales and input text fields on-the-fly in the LV screen using standard point and click/text editing methods.
The code is straightforward - no rocket science here. I use a simple serial port monitor/dispatcher running on the AB to respond to various command strings that are issued from LV. Youll find those commands documented in the code. For example, LV sends the string C2, to set the ADC channel # to 2, with the comma being used as a sentinel character.
Note that there are a couple of things in the code that Im currently working on (DAC support, and addition of a TSL235 light-to-frequency converter) - these are not being used by this LV program.
The primary purposes of this project are twofold - to introduce forum members to a very simple method for linking a program running on the Propeller back to LV and secondly, to see how to work with a LV run-time executable. As Ive mentioned previously, that exposes user data (that the Propeller is very good at acquiring) to a host of signal processing, analysis tools and graphics that would otherwise take a large amount of time to develop.
Additional features can of course be very easily be added to make this much more useful (file saving, arbitrary waveform generation etc etc) - which I hope to get to down the track if there is interest.
In the coming weeks Ill be giving top priority to finishing my website, which at the moment I'm finding is taking up most of my spare time. This will have many pages devoted to all kinds of scientific instruments (primarily for chemistry and physics) mainly Propeller, but some XMOS-based projects too. Some you've seen in this thread already, but there are many more.
I'm aiming for this to be a how-to guide that explains what the instruments measure, how they measure it and why thats important, and shows typical experimental results. I also plan to have more to say there about developing LV vis as those details are hidden away in the LV exe.
Happy experimenting .
Richard
I look forward to future posts.
Tom
Quite a good write up. The demo is code is great.
Thanks for the great Propellor support!
Jim
About the run-time engine. I see that there is a NI also offers a run-time engine for the Mac and one for Linux. I know nothing about how the run-time executables are built up. Is it very difficult to build them cross-platform?
The runtime executable is created by an Application Builder tool that is part of LabVIEW. After one is satisfied that a vi is working correctly , the .exe is very easily generated (it is accessed by a menu selection in LV). The following link explains the situation w.r.t transportability - whereas vi's are transportable cross-platform that is not the case for the executables.
For further information, have a look at http://digital.ni.com/public.nsf/websearch/39F868F9B64A61FC862569E70080BF34?OpenDocument
I checked with National Instruments this morning and and was told that my LV licence could be used on either a Mac or a PC. I actually wasn't aware of that so when I get a chance I'll investigate making a Mac application that would work with a Mac runtime engine.
Yes, my Propeller code is mainly PASM. I really haven't used SPIN that much as I'm more fluent in C, but probably like many old-timers here my first language was Fortran. Back in the early 70's almost all science students in Australia did some programming and I still remember the decks of punched cards that we used to submit at the front desk of the computer centre each night - only to read on the line printer output in the morning "fatal error on line 23" - my how things have changed since then...
I find PASM very easy to code in, the instruction set is flexible (and very good for I/O) and using it delivers good execution speed. I'm certainly no guru but I've learned enough to do a serviceable job. And the basic code here just needs slight modification for each new instrument that I'm working on - both at the PC end and at the Prop end - that's certainly a big bonus for rapid prototyping !
Thanks too for the positive feedback...
Richard
Time for that long overdue local prop meetup. I've sent a private message with my mobile number, let me know when would suit
regards
Lachlan
What programming language did you use for the Prop?
cheers,
rich
very good to chat earlier today - looks like a Melbourne Propeller meet-up is now pencilled in for Monday July 20th. I hope this advance notice might give other Aussies a chance to make it too !
regards
Richard
regards
Richard
That cost excludes the license for LabVIEW right? I'd think academia gets those licenses at deep discounts, but outside of it, LabVIEW isn't exactly cheap.
Yes you are quite right, LabVIEW licenses don't come cheap. I maintain my academic license for my PC, for which there is a 75% discount. Recently I investigated purchasing a separate Mac development environment (with the Application Builder) and was quoted A$1750, so ouch - A$7500 for a full-priced license. (Note that currently 1A$ = US$0.77).
The economics of LabVIEW do make sense in a teaching environment. Consider putting many low cost instruments into a large teaching lab where you have 150 students in a session - with individual experiments being conducted by groups of 2-3 students. You'll need just the 1 development environment to build the runtime executable(s) and then have the free LabVIEW Runtime engine imaged onto each PC. The economy of scale really operates to advantage in this situation.
I find the vast array of tools available in LV also allows one to develop complex instrumentation very quickly, particularly when any signal processing/data analysis is required. But this isn't meant to be a plug for LV, just my own experience with using it.
Some years ago I remember there being a LV student edition. It was indeed a low cost option and IIRC was sold via an arrangement between NI and one of the large publishers, but I'm not sure of the status of this now - could be worth checking out.
Richard
Do you think your instruments will work with the new home addition of Labview. https://www.digilentinc.com/Products/Detail.cfm?NavPath=2,1301,1450&Prod=LABVIEW-HE(link)
Jim
thanks for posting that information about the home edition of LabVIEW - very interesting. Lachlan emailed me about this which alerted me to check the forum to see your postings.
I'm on holidays with my family on the Amalfi coast in Italy at the moment but when I get back to Australia in about 3 weeks I'll definitely get a copy and try it out. I am optimistic that it will be a useful tool and certainly the price is attractive. It looks similar to the student edition that we used in the lab a few years ago and that version was quite capable
My site describes the suite of scientific instruments I've designed and built using both Parallax Propeller and XMOS processors. Over time my site (which has a strong educational focus) has evolved into a detailed record of what I’ve achieved and outlines the how and why.
I‘ve also included comprehensive explanations of the underlying science to provide context, as well as detailed descriptions of experiments/data to demonstrate how well my different instruments perform.
You’ll see that I’ve been working in a number of other areas of possible forum interest too, including FPGA’s, P1V, P2, and HyperRAM - to name a few. Be sure to check out some of the items under the Test+Measurement menu that just didn’t logically fit anywhere else.
I’ve really enjoyed building this website. I’m hoping the instruments and experiments I've described will offer others real insights into how one can undertake scientific investigations on a limited budget using high quality, home-grown instrumentation – enjoy.
Richard
Looks cool...
Do you have reference code for HyperRAM - even if done for XMOS, it would help P1/P2 coders.
Did you test areas not covered in the data sheet, like do the parts refresh while CS# is high (no clk), or is a clock needed ?
Did you confirm a continual write/read inside the max times, is enough to refresh the used subset of memory ?
Do you need to use the handshake lines, or is timing enough ?
Didn't notice anything else obviously wrong, but then again I only spent a few seconds. Looked clean and nice though.