...as a general rule, P1 pins are sensitive to weak fields. If you do nothing but attach a wire to a pin, you will see all kinds of frequencies. The longer the wires, the more you see. So, you should pull the pins to ground through a resistor, and you might need a shielded wire to the sensor.
I've had the same sensors run in an edge counting sketch in arduino using interrupts and they have had stable readings for upwards of a few weeks. I switched to propeller so I can get more sensors in one experiment. They've also been sitting at room temp and have not moved much so not sure if that is the real issue here. If it's the crystal then is it doomed from the start? Maybe if I put an oscilloscope to the sensor outputs and check to see if the actual square wave drifts that quickly....
Those drifts are far above what any xtal might do, so certainly check with a good scope with a frequency counter, or feed in a TCXO divided as a test signal, or check a 1pps signal from a GPS module.
(just maybe, Prop is running on HFOSC (default) and not switched over to Xtal+PLL ?)
Properly set up, the granularity of a Prop Reciprocal Counter should be much better than an Ardunio.
You can calculate the granularity (LSB size) easily enough for any nominal gate time.
If we assume a 100ms gate to read 10Hz, and an 80MHz SysCLK, we get counts of 8M for ~ 0.125 parts per million, numeric granularity.
The only remaining issue is this constant drift from the moment the spec's turn on.
Do you have a commercial reciprocal counter ? - or, you can divide the 500kHz test values to bring into Audio range, and use a sound card as a frequency counter.
If you add a simple RC filter to turn the square waves into ~triangle waves, you should get precision in the single digit ppm, and accuracy set by your PC sysclk (usually within 200ppm)
Note that while single-cog, sequential sampling designs are simple, they do not read all sensors at the same time - I'm expect that detail matters in your application.
From Bean's post above, you can fit 2 counters per COG, and if one COG manages COMs, & testing, that indicates 14 counters can fit.
Note that with paired counters, both channels need a signal, to avoid a stall condition, in the wait-for-edge state.
One approach might be to allocate 4 longs in HUB for each counter, to pass
PinToSample : Written from PC, read by fcCOG to select which pin to measure.
SampleCount : Written by fcCOG, increments on every >gate update
TotalTIme: Written by fcCOG, 32b time value, not cleared.
TotalCycles: Written by fcCOG, 32b cycles count, not cleared.
COMs link sends 3 x 32b x 14 channels to PC, and PC sends 14 x COG:Pin select values, plus an optional test pin Freq set value.
The PC end subtracts Time and Cycles to give a difference, skipping clear avoids cases where clear and edge arrive on same sysclk
By sending a PinToSample from the PC, you can easily have a test pin(s) on one or more Prop pins, and this also allows that test pin to provide a signal for odd-sensor counts (to avoid stalls)
Connect a 1pps GPS module, and you have a second test path, that allows 1-second crystal calibrate, that should allow easily sub 1ppm system accuracy. (Bean's code works to 0.5Hz for this reason)
Roughly 30ms is needed to send as 32b values, at a modest 115200, but ~ >100ms is needed to read as low as 10Hz, so you should be quite comfortable.
(30ms assumes 3 23b values hex encoded, and a CR or similar, it can drop to ~ 13ms if you use 7b offset ascii encode, and send SampleCount as 7b, Totals as 5x7b, + CR)
SampleCount is not mandatory, but is useful to confirm no skipped or lost samples during system operation.
Hi Everyone,
Sorry for the radio silence had a backlog of papers to read regarding our project. So as it turns out there WAS a settling of the signal to a near driftless line which lasts well over a day with hardly any noticeable change. I even placed them in the shaker at 250rpm as a simulation of experimental conditions and no issues. Everything seems to work as it should so my deepest gratitude to everyone that has helped on this project. I'll be sure to cite you in the paper and ensure the credits remain in the source code as well.
The only curiosity left is WHY the sensors need to settle before they stabilize. Same reading occurs if the sensors are in a temperature stabilized incubator (37 C) or in the fluctuations of natural room temperature. Consistent decay time too. Attached are images both zoomed in and scaled to experimental ranges. X axis is in seconds. Y axis is in frequency. The image scaled 0.000 to 2.000 is the absorbance reading over almost one whole day. Short term (1hr) and long-term (overnight). Any idea why this is a thing? Thanks!
Hi Everyone,
... So as it turns out there WAS a settling of the signal to a near driftless line which lasts well over a day with hardly any noticeable change. I even placed them in the shaker at 250rpm as a simulation of experimental conditions and no issues. Everything seems to work as it should so my deepest gratitude to everyone that has helped on this project. I'll be sure to cite you in the paper and ensure the credits remain in the source code as well.
The only curiosity left is WHY the sensors need to settle before they stabilize. Same reading occurs if the sensors are in a temperature stabilized incubator (37 C) or in the fluctuations of natural room temperature. Consistent decay time too...
Tip: Clearer axis & graph labels also help a lot.
Settling times are expected on pretty much any 'significantly zoomed' analog system/sensor.
You do not say if the decay is from power up, or applies from first reading, (ie no matter how long power has already been applied).
I would expect a Power up settling time, as the die + sense element needs to stabilize.
Note some system designs, include a dummy sensor, with fixed conditions, as a 'zero' tracking device - so if this settling time is a problem in use, you could look to include that.
As not all curves are identical, this improves things, but does not eliminate the effect entirely.
Another alternative is to store a calibrate curve for every sensor startup, or write some software that tracks and removes a fitted settling curve.
The drift appears to be about 10% from the graphs.
Most parts are affected by supply voltage. The TSL235R is pretty stable. A 2 volt variation would cause a 1% variation in measurement. Your power supply is likely much more stable.
The datasheet advertises a 150ppm/C temperature coefficient. If we assume 2mA of supply current at 5v, that's 10mW. The datasheet doesn't specify degrees C/ Watt, let's assume 200C/W based on its similarity to a TO92 package. So the sensor will warm up at least 2 degrees C from its own power consumption. At 150ppm/C that's 300ppm or .03%.
If your light source generates a significant amount of infrared, the ppm/C could be as high as 6000. That gets us to 1.2%. To get 10%, that would mean a temperature rise of 17 degrees C. With the other assumptions that means a supply current of 17mA. My estimated degrees C/Watt could easily be off by a factor of 2 or more. If the cables are long, that could increase the power consumption. The datasheet recommends 12 inches maximum wire length. If the sensor is powered by 5v it will add 0.5mA average current through the protection resistors on the ASC+. You might find it interesting to measure the current consumption of a sensor.
Don't forget that the sensor is also heated by the light that it absorbs.
Counterfeit parts are a possibility. If you bought from authorized distributors this should be very unlikely.
Comments
...as a general rule, P1 pins are sensitive to weak fields. If you do nothing but attach a wire to a pin, you will see all kinds of frequencies. The longer the wires, the more you see. So, you should pull the pins to ground through a resistor, and you might need a shielded wire to the sensor.
Those drifts are far above what any xtal might do, so certainly check with a good scope with a frequency counter, or feed in a TCXO divided as a test signal, or check a 1pps signal from a GPS module.
(just maybe, Prop is running on HFOSC (default) and not switched over to Xtal+PLL ?)
Properly set up, the granularity of a Prop Reciprocal Counter should be much better than an Ardunio.
You can calculate the granularity (LSB size) easily enough for any nominal gate time.
If we assume a 100ms gate to read 10Hz, and an 80MHz SysCLK, we get counts of 8M for ~ 0.125 parts per million, numeric granularity.
Do you have a commercial reciprocal counter ? - or, you can divide the 500kHz test values to bring into Audio range, and use a sound card as a frequency counter.
If you add a simple RC filter to turn the square waves into ~triangle waves, you should get precision in the single digit ppm, and accuracy set by your PC sysclk (usually within 200ppm)
Note that while single-cog, sequential sampling designs are simple, they do not read all sensors at the same time - I'm expect that detail matters in your application.
From Bean's post above, you can fit 2 counters per COG, and if one COG manages COMs, & testing, that indicates 14 counters can fit.
Note that with paired counters, both channels need a signal, to avoid a stall condition, in the wait-for-edge state.
One approach might be to allocate 4 longs in HUB for each counter, to pass
PinToSample : Written from PC, read by fcCOG to select which pin to measure.
SampleCount : Written by fcCOG, increments on every >gate update
TotalTIme: Written by fcCOG, 32b time value, not cleared.
TotalCycles: Written by fcCOG, 32b cycles count, not cleared.
COMs link sends 3 x 32b x 14 channels to PC, and PC sends 14 x COG:Pin select values, plus an optional test pin Freq set value.
The PC end subtracts Time and Cycles to give a difference, skipping clear avoids cases where clear and edge arrive on same sysclk
By sending a PinToSample from the PC, you can easily have a test pin(s) on one or more Prop pins, and this also allows that test pin to provide a signal for odd-sensor counts (to avoid stalls)
Connect a 1pps GPS module, and you have a second test path, that allows 1-second crystal calibrate, that should allow easily sub 1ppm system accuracy. (Bean's code works to 0.5Hz for this reason)
Roughly 30ms is needed to send as 32b values, at a modest 115200, but ~ >100ms is needed to read as low as 10Hz, so you should be quite comfortable.
(30ms assumes 3 23b values hex encoded, and a CR or similar, it can drop to ~ 13ms if you use 7b offset ascii encode, and send SampleCount as 7b, Totals as 5x7b, + CR)
SampleCount is not mandatory, but is useful to confirm no skipped or lost samples during system operation.
Sorry for the radio silence had a backlog of papers to read regarding our project. So as it turns out there WAS a settling of the signal to a near driftless line which lasts well over a day with hardly any noticeable change. I even placed them in the shaker at 250rpm as a simulation of experimental conditions and no issues. Everything seems to work as it should so my deepest gratitude to everyone that has helped on this project. I'll be sure to cite you in the paper and ensure the credits remain in the source code as well.
The only curiosity left is WHY the sensors need to settle before they stabilize. Same reading occurs if the sensors are in a temperature stabilized incubator (37 C) or in the fluctuations of natural room temperature. Consistent decay time too. Attached are images both zoomed in and scaled to experimental ranges. X axis is in seconds. Y axis is in frequency. The image scaled 0.000 to 2.000 is the absorbance reading over almost one whole day. Short term (1hr) and long-term (overnight). Any idea why this is a thing? Thanks!
Tip: Clearer axis & graph labels also help a lot.
Settling times are expected on pretty much any 'significantly zoomed' analog system/sensor.
You do not say if the decay is from power up, or applies from first reading, (ie no matter how long power has already been applied).
I would expect a Power up settling time, as the die + sense element needs to stabilize.
Note some system designs, include a dummy sensor, with fixed conditions, as a 'zero' tracking device - so if this settling time is a problem in use, you could look to include that.
As not all curves are identical, this improves things, but does not eliminate the effect entirely.
Another alternative is to store a calibrate curve for every sensor startup, or write some software that tracks and removes a fitted settling curve.
Most parts are affected by supply voltage. The TSL235R is pretty stable. A 2 volt variation would cause a 1% variation in measurement. Your power supply is likely much more stable.
The datasheet advertises a 150ppm/C temperature coefficient. If we assume 2mA of supply current at 5v, that's 10mW. The datasheet doesn't specify degrees C/ Watt, let's assume 200C/W based on its similarity to a TO92 package. So the sensor will warm up at least 2 degrees C from its own power consumption. At 150ppm/C that's 300ppm or .03%.
If your light source generates a significant amount of infrared, the ppm/C could be as high as 6000. That gets us to 1.2%. To get 10%, that would mean a temperature rise of 17 degrees C. With the other assumptions that means a supply current of 17mA. My estimated degrees C/Watt could easily be off by a factor of 2 or more. If the cables are long, that could increase the power consumption. The datasheet recommends 12 inches maximum wire length. If the sensor is powered by 5v it will add 0.5mA average current through the protection resistors on the ASC+. You might find it interesting to measure the current consumption of a sensor.
Don't forget that the sensor is also heated by the light that it absorbs.
Counterfeit parts are a possibility. If you bought from authorized distributors this should be very unlikely.