Mistakes in Arduino example

[Alexey-Danilchenko]

Hi,

The Arduino example you have (arduino_csv_example.ino) seem to have a few mistakes.

Line 76: int numIntegrationBlocks = (intTime * 1000) / blockTime;
Here the numIntegrationBlocks will overflow as on Uno it will not fit in 15 bit signed integer and the following loop never executes

Line 49: int read_time = 35; // Amount of time that the analogRead() procedure takes (in microseconds)
The comment at line 130 is actually more correct - on Uno analogRead() will take 111 microseconds (according to http://meettechniek.info/embedded/arduino-analog.html). In any case what the read_time is set to seems to be quite a way off.

Could you please correct them since the project is shared publically?

[PeterAJansen]

I think this code was adapted from my original version for the ChipKit, which uses a PIC32 processor, and is substantially faster. While the ChipKit platform advertises as being Arduino compatible, there are still some minor differences (like these) if you're using it on something like an Uno.

[PureEngineering]

I think at some point I will need to change it from loop based timing to
use a actual timer for timing.

On Fri, Sep 25, 2015 at 10:19 AM, PeterAJansen notifications@github.com
wrote:

I think this code was adapted from my original version for the ChipKit,
which uses a PIC32 processor, and is substantially faster. While the
ChipKit platform advertises as being Arduino compatible, there are still
some minor differences (like these) if you're using it on something like an
Uno.

—
Reply to this email directly or view it on GitHub
#1 (comment).

Sashi Ono
Principal Embedded Systems Engineer
(805) 699-6690
www.pureengineering.com

[Alexey-Danilchenko]

Peter, PureEngineering

I guessed as much - but this is published as working example for Uno and I have my doubts as to whether it actually is working.

I have a little project of my own with Hamamatsu spectrometer - mine is based on Particle Proton board and separate ADC with dual reference voltage. At the moment I am basing it on Arducoder and PureEngineering work so thank you both very much for paving the way (figuratively speaking ;)

I will publish the schematics, board and code on GitHub when its done and tested.

[Alexey-Danilchenko]

There is still a problem. With the timings you use for delay and analogRead() I cannot see how consistent integration time can be achieved. The pulse timing is 1 microsecs and the read time configured 35 microsecs (which is not happening by the way on Uno unless you manually setup a gain to lower the integration time) which means that all the leading and trailing pulses will be 1 microsecs long and the one where reading occurs 112 microsecs long (on Uno). All the integration times will be skewed across the cells because they do not account for that (and integration according to Hamamatsu docs starts from reading one sensor channel to another reading of the same channel).

Why isn't analogRead() used to provide a period for clock (even if what it reads is fake) instead of delayMicroseconds(delay_time)? That would solve the problem of unevenly spaced clock and will provide reliable integration timings.

[PeterAJansen]

My original driver uses an external high-precision ADC with known read
times -- this might be a good choice for you if you'd like to have more
precise integration times.

On Tue, Sep 29, 2015 at 8:22 AM, Alexey-Danilchenko <
notifications@github.com> wrote:

There is still a problem. With the timings you use for delay and
analogRead() I cannot see how consistent integration time can be achieved.
The pulse timing is 1 microsecs and the read time configured 35 microsecs
(which is not happening by the way on Uno unless you manually setup a gain
to lower the integration time) which means that all the leading and
trailing pulses will be 1 microsecs long and the one where reading occurs
112 microsecs long (on Uno). All the integration times will be skewed
across the cells because they do not account for that (and integration
according to Hamamatsu docs starts from reading one sensor channel to
another reading of the same channel).

Why isn't analogRead() used to provide a period for clock (even if what it
reads is fake) instead of delayMicroseconds(delay_time)? That would solve
the problem of unevenly spaced clock and will provide reliable integration
timings.

—
Reply to this email directly or view it on GitHub
#1 (comment).

[Alexey-Danilchenko]

That's not what I was referring to. Whether external or internal ADC - the point of uneven timings and incorrect integration remains.

My design uses AD7942 ADC with two selectable references

[PeterAJansen]

The example the groupgets folks have here is derived from my original driver for the Chipkit, and that driver had reasonably accurate timings for the platform and ADC, minus some offset for the reading (if I remember correctly, when timing it on an oscilloscope). It was intended to be an easy-to-understand and easily portable example to get folks up, running, and collecting data from this beautiful instrument quickly.

There are many things that are not included or could be improved in this simple driver -- for example, it doesn't include spectral compensation (datatsheet pg 3, upper left), nor does it compensate for the varying point-spread function (pg 3, upper right), or include the device-specific calibration standards provided with each microspectrometer. The timing is also not microsecond or even millisecond accurate on any platform.

Being a work of open source, I have authored the original driver and placed it freely available for download in the hope that folks will find it useful, and (if they're so inclined), improve upon it. If your application requires millisecond-accurate integration timing or any other features on the Uno (or any other architecture), you're both free and encouraged to incorporate these changes, and submit them to be included in this repository. I only ask that if you include platform-specific code, that you wrap them in #define statements to make sure it doesn't break the code on other platforms.

best wishes,
Peter

[Alexey-Danilchenko]

Peter, I understood pretty well where the code was derived from. But my comment about problem has nothing to do with your code or its accuracy. It also has nothing to do with the code I am writing (that is as accurate as I need). Your or mine code are for specific applications, this however is a generic code for generic use and as such it can at least benefit to be accurate starting point. Isn't this the point of having it open source as well - to make it better?

Now if we look at this example (not Arducoder's code) then how having 1microsec timing pulses and amonst them having regular 112 microseconds reading pulse per single channel reading is making timings even remotely accurate? I am not after microseconds accuracy but 100 fold difference in timing pulse length does not sound reasonable. Of course it is very dependent on what Arduino board is used - I am reporting with respect to Uno since this is what this project specifies in a readme.

Ti make it better, the timings of the delay for the regular clock pulse could be aligned with the readAnalogue() timings for example. Or to make it universal for any Arduino board as I said it could be improved by simply using analogRead() (fake ones) instead of delayMicroseconds() to provide clock pulse timing - this is easier than calculate the times it takes for each Arduino board type and code them in constants.

[medic-IT]

Why are we using a breakout bord instead of using directly the C12666MA on the arduino bord ?

[Alexey-Danilchenko]

The sensor is analogue and needs good filtered analogue power supply to have stable results. According to my tests noise on controlling signals diminishes performance so good filtered power supply (including buffer chip) and clean digital signals are essential. In addition, the sensor in no-gain mode gives fully saturated output level at about 3V and in gain mode - about 4V. Using 5V 10 bits ADC directly will reduce the resolution and loose one bit just because of that.

I have resorted to create my own board with a socket for sensor and Particle Photon to control it with fast 14bit ADC and analogue filtered power supply chain. When fully debugged, both board and code will be open sourced (all works now I am merely tuning software and hardware bits).

[medic-IT]

Hello Alexey-Danilchenko,

Thank you for your answer.
I also appreciate your comments about the code (The Arduino example).
I've read the datasheet but i don't really understand the how to create the ST pulses and read the sensor outputs.

Could you, please send me, what (correct code) you think would have been the right way to drive the sensor, with some comments ?

Best regards

[Alexey-Danilchenko]

Not yet. My code will be opensourced when all is working properly - not far now.

[PeterAJansen]

If you'd like a working example with an external 14-bit ADC, you can see my
reference code from the Arducorder Mini at:

https://github.com/tricorderproject/arducordermini/tree/master/firmware/examples/spectrometer_c12666ma_example

The schematic is also in that repository. The schematic includes only a PI
analog filter, and analog isn't my forte, so please let me know if you have
a better filtering scheme. The Arducorder Mini is powered by a ~3.3V
LiPoly battery -- so it doesn't have the same issues as the somewhat noisy
USB-powered Arduino Unos -- but it does use a small booster to raise the
3.3V to 5V for the microspectrometer, so this does introduce a bit of noise.

In either case, you really have to use an external ADC with this to get a
useable range. The Hamamatsu development kit uses a 16-bit ADC, but since
the clock speed on the spectrometer doesn't have to be terribly fast, you
can use a 14-bit ADC and oversample by 16x to functionally achieve near the
same resolution for much less cost and difficulty.

best wishes,
Peter

On Sun, Jan 24, 2016 at 1:13 PM, medic-IT notifications@github.com wrote:

Hello Alexey-Danilchenko,

Thank you for your answer.
I also appreciate your comments about the code (The Arduino example).
I've read the datasheet but i don't really understand the how to create
the ST pulses and read the sensor outputs.

Could you, please send me, what (correct code) you think would have been
the right way to drive the sensor, with some comments ?

Best regards

—
Reply to this email directly or view it on GitHub
#1 (comment).

[medic-IT]

Ok, I'll will be waiting for it.

just an other question about the c12666ma sensor, I don't really understand the Arduino example :
how he drive the sensor's différents clocks. could you give me more comments on the readSpectrometer() method ?

thank you

[Alexey-Danilchenko]

medic-IT, not really sure I understand the question