Firmware revision

I’ve been looking at noise from different angles and the result is a new firmware release for the TCD1304 driver.

There are few important changes, like new GPIOs for the connection to the CCD and I will update the tcd1304.wordpress.com site in the coming days.

If you cannot wait, everything (I hope) is of course documented in the source code.

TCD1304 driver firmware for STM32F401RE nucleo board. Rev. 020217

And below are the boring details:

1: Crosstalk between analog and digital lines

I have no idea how the circuit is laid out inside the STM32F401RE, but on the outside it looks like this:

stm32f401re-pkg

The previous firmwares had output on PA0 and PA1. Right next to Vref+ and Vref- which the ADC measures input against. The alternate-function mapping didn’t allow for moving the output on PA1, but the output on PA0 has now been moved to a physically more distant GPIO.  For reasons I can’t remember I also moved fM away from PA6.

PA0, PC2 PB0 and PB2 are now pulled down and can be connected to GND to make for a virtual ground at GPIOs around the ADC and the noisy high frequency fM.

2: Speed limits

The GPIO speed has been limited to 25 MHz for all communication and driving pulses.

3: Typical CCD driving and ADC sampletime

The datasheet for the TCD1304 specifies 2.0 MHz as the typical master clock. I have no idea if driving at other frequencies will degrade the performance of the CCD, but the fM has now been increased from 1.4 to 2.0 MHz.

The fM is now defined in main.h and the clocks and periods for the timers for all the other driving pulses are derived from this. You can even change the system core clock and still have proper output, because fM-period is calculated from the APB1-clock,

On the same note the ADC sampletime has been increased from 3 ADC clockcycles to 15.

4: Proper flushing

Obviously this gives a cleaner everything. Seriously though, with proper attention to the pulse sequences just before data-acquisition, the linear CCD module performs much better.

5: Bug fixed

The annoying bug described in the previous post has been squashed. Still the occasional connection issue persists.

Troubles from the past

Jens-Ulrich Fröhlich built my  OtterVIS-LGL spectrophotometer and he reported that changing the pulse counter in the interrupt handler from 2 to 3 improved stability of the readings.

This is correct, so I decided to figure out why, after all I don’t want to wait one integration too long (or too short) for getting a proper reading.

The situation with a pulse counter of 2 looks like this:

flush-CCD-pulsecount51.png

The blue trace is the ICG pulse, which determines when the pixels are dumped into the TCD1304’s shift registers and read by the ADC. The ICG timer runs with a certain period (the first four pulses) until the MCU receives the new settings (pulse #5) somewhere after the fourth pulse. Then follows 2 pulses with a short period to clear the CCD, and then the ADC is started.

Of course this is undesirable, and with a pulse counter of 3 the new trace looks like:

flush-ccd-pulsecount61

The ADC start trace (red) is actually a GPIO that’s set high at ADC-DMA Half-Transfer interrupt and set low again at ADC-DMA Transfer-Complete, in case your wondering why it doesn’t start right when ICG goes high.

Here is a close-up of TIM4 (that paces the ADC) tied to a GPIO together with ICG:

icg-and-tim4_01

fM (not shown) is 2.0 MHz and TIM4 is fM/4 ie. 0.50 MHz. The timer starts with a negligible delay¹ after ICG goes high, and is turned off 7.4 ms later, just as expected (3964 / 0.50 MHz = 7.4 ms).

I’ve also checked if the DMA_SxNDTR is counting properly, and at 3.7 ms after ICG it’s 1848 and at 7.4 ms it’s 3693 (the DMA is circular and NDTR is reset at the end).

In short I’m fairly certain the timers and their interrupts are behaving consistently and as expected.²

Now comes the puzzling part. Spending the entire weekend looking at the output, I’ve realized that someting odd is going on:

When new settings are received, the MCU is supposed to wait for the ADC-DMA Transfer-Complete interrupt before transmitting the collected pixel values back to the PC. However this is apparently not the case. There are owles in the marsh (as we say in Denmark).

  • For long ICG-periods the consequence is that the MCU transmits the contents of aTxBuffer before it’s updated, ie. you get the previous reading. For some applications this is not a problem. You just collect twice, but if your sample is changing with time this is of not very desirable.
  • For shorter ICG-periods you will see part of a new read and part of the old, and the frame shifts at pixel number: ICG/170. Again you can just collect twice and the problems goes away – if you can collect twice..

The behaviour is of course unacceptable and will be fixed. For now you know it exists!

 

¹ There are 32 dummy pixels, so with fM = 2.0 MHz theres 16 µs to eat at, but enabling and disabling TIM4 by manipulating directly with the TIM_CR1 register is fast enough that TIM4 is running even before ICG goes low.

² The timer update interrupt appears to also be called when the timer settings are changed. I’ve not looked into the reference manual, but the answer is most certainly there.

Raman has no reflection in the (dichroic) mirror

So I got tired of trying to align the little prism you can’t see in this picture (The one sitting between the microscope objective and the optical fiber assembly):

dsc02335

It’s been replaced with a 540nm long pass dichroic mirror:

dichroic-raman-1

And from above:

dichroic-raman-0

And finally with a 532nm laser pointer shone upon it:

dichroic-raman-2

It’s not perfect. The reflection is not quite 100%, and it is going to cost me on 10-20% of the intensity of the Raman scattered radiation. Hopefully the improved alignment will make up for some of this.

The system now more closely resembles a commercial Raman probe:

new-look

Tired of pi – try UART

The first functional UART-enabled firmware and GUI is ready.

You can now run the Otterly CCD GUI directly on your computer without the need for that annoying little rpi. Downside is the speed. UART is app. 150x slower than SPI.

So why bother with an even older and simpler communication protocol than SPI?

Well for now there’s no good reason except you save yourself the trouble of having to connect the rpi and nucleo. The real reason to go with UART is that without a master, the MCU can now decide when to transmit. This may not seem like a big deal – and it probably isn’t – but I haven’t been able to reliably do timed reads of the CCD using SPI. This will change (someday soon).

For downloads and slightly more info goto: tcd1304.wordpress.com

A waste of time

While it was “fun” to destroy a quartz cuvette and bring it back to life, it was also a complete waste time.

The point of the whole operation was to bring the focal point of the microscope objective inside the sample volume by reducing the wall thickness of the cuvette from 1.25 mm to 0.75 mm.

The microscope objective has a working distance (WD) of 1.0 mm in air, which means that the WD is >1.0 mm in any medium with a refractive index >1.

I’ve tried to photograph the focal point:

The images show fluorescein’s emission by excitation with a 532 nm laser. The spectroscopic cell has a wall thickness of 1.25 mm. The difference in the illumination angle is due to a difference in the diameter of the collimated laser light entering the microscope objective.

If you really want you can sort of persuade yourself to see that the light is focused just inside the spectroscopic cell. If you’re more of a sceptical kind of person you’ll need more pictures:

This is tetraphenylporphyrin’s emission by excitation with the same laser. The image on the right is just a crop. Here it’s clear that the light is focused somewhere inside the sample liquid.

The A is for asynchronous

In SPI two or more devices communicate and the transmission rate is dictated by the master’s SCLK. Because the SCLK is shared between all devices it’s reliable even at very high speed – the STM32F401RE’s fastest SPI peripheral is good up to 42 MHz.

In UART two devices communicate with agreed-upon speed, character length, parity bit and number of stop bits. To transmit a byte one typically needs to send 10 bits: 1 start bit, 8 data bits and one stop bit. The two devices don’t share a clock – this is the asynchronous part – so if the actual speed of your two UARTs are not the same, you’ll run into trouble at high baud-rates, and that’s exactly what I did.

The remainder of this post is about the exploration of some of the Nucleo board’s various clocks. To spare you from high expectations, the conclusion is that I’ve not reached a higher baud-rate than 230.4 kBps for USART.

Continue reading

More glass – or less

This isn’t the first post about focus. In the previous post focus it became very clear – to me at least – how important proper focus is for the throughput of the optical system. The previous post was only about the planoconvex lens and the optical fiber. This will be about the microscope objective and the sample.

In the very beginning of my Raman shopping spree I aquired something that looks a lot like a Nikon CFI Plan Apo VC 20X. And you know what they say: If it quacks like a duck..

The microscope objective is very suitable for (this) Raman application because of the very large numerical aperture¹ (0.75) and the large diameter of the exit pupil (app. 14mm):

The catch is that the working distance is 1 mm. It’s on the low side of what you’d expect for 20x microscope objective, but I guess it’s the trade-off for the high NA. So what’s the problem with that then?

Continue reading