Sciencemadness Discussion Board

Building a polarimeter

 Pages:  1    3

smaerd - 7-6-2015 at 10:50

Aga I'm going to team stepper motor. I'll take you up on your offer but I'll at least throw something your way.

I'm very sure that the interrupt processes on the background are destroying this, or the encoder on the motor is bogus. The RAM can get rid of the serial interrupts but who knows what other interrupts may be interfering. But at this point I tried everything, even moving the encoder power supply to a separate supply and trying to eliminate PWM. Rather then tread water and try to run up hill, steppers are the way to go. It's really a shame I spent so much time with this stupid DC motor-encoder.

Aga the path-length only matters for how far the light travels through the solution you are measuring. I found a cheapy polarimeter sample cell on ebay for I think 30$. But one could be crafted from some copper tubing and microscope slides.

aga - 7-6-2015 at 11:10

The DC motor/encoder has led to all sorts of useful DSP routines you now have in your library, plus some valuable experience, so not all a waste of time !

Using a stepper will be much much simpler way to achieve the aim of the project.

smaerd - 7-6-2015 at 16:16

Aga - Once we start microstepping this will be perfect. Even if we can only get 16 microsteps per step on a 1.8* stepper. That's better resolution then I was getting before. I should have bought a 0.9* stepper instead of a 1,8*. Unfortunately this change puts me off the project for almost a month. China shipping yarrr. In the mean time if you have an questions or are making progress I'd love to see it!

edt - and your right. I learned a shit ton about electronics by doing the encoder approach. Things I would have never bothered learning otherwise. I asked a forum of experts what's going wrong, and the biggest suggestion was the encoder I bought being really noisey. Pretty unfortunate.

[Edited on 8-6-2015 by smaerd]
Edit - I did conjure up an alternative to using a stepper. It involves a physical mechanism. It would have to stop the gear after ~180*(or greater) Then no motor drift would occur and the counts could be counted. The motor spun backwards to reset against the same type of catch mechanism, etc. I just lack tools and prefer to use a stepper at this point :).

[Edited on 8-6-2015 by smaerd]

m1tanker78 - 8-6-2015 at 10:05

Quote: Originally posted by smaerd  
m1tanker - I decided that the next phase is going from the ground up in the arduino and debugging. It's a tricky environment to navigate because it is not 'low-level' so processes do things that are not explicit. Example: I've discovered the serial functions are a 'threaded'/interrupt process, so it can interrupt other operations at indiscernible times. So I am switching to an external SPI RAM chip (23LC1024) which supports 5V logic levels. Digital write operations only take about 10 nSec (using low level commands) and do not poll back or hault or any nonsense. I estimate I'll be storing data to transfer later ~100x faster then calling serial.

...

Thinking of switching to a raspberry pi.


Would the raspberry pi be more reliable with regard to interrupt-driven events than the arduino?

smaerd - 8-6-2015 at 10:25

M1tanker78 - I think it would be. This is because interrupts do not really occur on the rPi. If they do occur they are processes which the operating system cannot access (so they are really low level). Nevertheless the raspberry pi has a ~300MHz-700MHz clock cycle(on the old version) which can poll way faster then an arduino can interrupt. About 10-100 times faster than that of the common arduino boards. So missing encoder counts would only be the result of horrible programming practices.

The biggest downside to the raspberry pi is that it does not have an ADC on board (for the analog photodiode measurements). So if I were to have gone that route I'd have to buy an ADC and a break out kit. Which is no big deal probably costs 15-20$. However, the stepper motor and driver is the same exact cost.

The upside to the rPi is that there is 512mb of RAM(newer versions are 1gb iirc) which could hold, store and process all the data I wanted it too and could stand alone without a separate computer. Could even transfer the information via WIFI or similar.

The biggest downside would be tearing down all of my JAVA and arduino code and starting over in python. The second biggest problem with keeping the motor-encoder and switching firm-ware/hard-ware would be, if the encoder is bogus. then it's wasted effort/cash. It seems like the encoder is bogus, I think there is an interference with the 12V 1A driving line being 1-2mm away from the encoder lines.

That's basically the debate that lead me to using a stepper motor. It's faster and easier (if the code is given for free). Someone would be more likely to follow this type of build imo.

edit - it's another one of those, if I had an oscilloscope problems. Oh jeese, the amplification circuit would have been done in 2 days max, I'd of diagnosed this problem months ago. Hahaha, one day I'll be able to invest in one.

[Edited on 8-6-2015 by smaerd]

aga - 8-6-2015 at 12:08

The Pi runs linux and has an HDMI TV interface, so a whole host of interrupts going on, hardware and software.

You'd have to shove some flavour of RealTime Linux onto it to get anything like a time-fix to your program.

The free-running motor with encoder thing can be done, no doubt about it, just that for a $5 investment in a stepper motor this project can be completed and very easily replicated by others, and for a much lower overall cost.

Not so sure a 'scope would have told you enough, given that the arduino has 'other internal processes' going on.

A working digital 'scope need not be too pricey :-
http://www.ebay.co.uk/itm/Digital-display-Oscilloscope-200KH...

i got one of these :-
http://www.ebay.co.uk/itm/Quad-4-channel-Portable-Digital-2M...
2 channels are digital only, and i broke 1 of the two analogue channels, so i'd have been better off with the £16 version.

Still, very good as a 'scope for my purposes.

m1tanker78 - 8-6-2015 at 15:46

@aga: Isn't there an external chip that handles, for example, HDMI protocol. No good for GPIO-driven interrupts although I'm reading that newer pi kits support GPIO interrupts. Other than a faster clock speed, what's different about interrupt handling routines in a pi and, say, a PIC or arduino? It would be sweeeet to throw some Python at the board and go without debugging interrupt failures.

@smeard, shouldn't be too difficult to translate your routines to Python. Heck, I feel like I'm sort of cheating when I write Python scripts or DSP blocks. Speaking of which, have you ever checked out "GNU Radio"? There's a whole host of DSP blocks that you can tweak to your liking or write your own. If nothing else, it's great for experimenting with generating and processing waveforms. It's used mostly for RF stuff but should be similar (or identical) regardless of frequency of interest.
Quote:
it's another one of those, if I had an oscilloscope problems.


I sold my old Tektronix scope last year and have kicked myself a few times for letting it go. I've been getting by with a FPGA core I created that acts like a crude digital sampling scope but it's not quite the same.

Correct me if I'm wrong, wouldn't you still need at least one reference point on the stepper-driven wheel? Or would you be using the peak/zero crossing as a phase detector?

smaerd - 8-6-2015 at 17:27

Aga - I'm gonna save up so I can get a nice used one. Something that I can get like 10+MHz that way I have a tool I can rely on effectively for life and almost any application I'd need.

m1tanker78 - It wouldn't be hard and python would execute faster. I just have never written GUI in python before. It's the little things that take the longest in my experience. Chances are I could do that in an afternoon though.

I haven't heard of GNU Radio but if I ever do switch to an rPi I'll look into it. I have an rPi sitting around waiting for a project but I think it would be better suited to something more involved. All I'd need would a fast fourier transform and to see some examples of how they handle basic GPIO and I'd be good to go (I think).

Yes I will still need a reference point. The difference with the stepper is that there should be no motor drift. The DC motor-encoder failed only at one task, counting how many encoder pulses had occurred after the motor had been turned off. Sounds ridiculous right? But either the serial buffer was chopping into the counts, or the majority of the counts were occurring while I was turning off the motor. Or the encoder was bad. So frustrating and nearly impossible to discern.

The zerocrossing algorithm is so easy. It enabled me to actually simplify my routine greatly. It now goes like this,

Run motor 180* -> find zero cross and count drift -> rotate 180* -> find zero cross -> Add drift to zerocross and turn into degrees.

I might still do the rotation to a minimum routine just because the results look nicer.

m1tanker78 - 8-6-2015 at 18:34

Quote: Originally posted by smaerd  
The DC motor-encoder failed only at one task, counting how many encoder pulses had occurred after the motor had been turned off.


Ahhh, now I understand why you've been harping on the encoder so much. As I mentioned before, all you really need is a single 'tick' on the wheel that triggers a hard interrupt. It could be optical, magnetic, even a paddle switch and a popsicle stick glued on the wheel (yes, I've been that desperate and/or broke before). Count 2 ticks and shut the motor off (you're no longer sampling at this point). You now have more than enough measurement points ... a full period and then some. Start the sending routine. Do the same for the sample cell run. Use zero crossing phase detector (on the computer) and take it from there. The motor can drift all it wants without worries.

In this way, the uC doesn't sample/count and send data at the same time.?.?

EDIT:
--------------------

I forgot to mention that you somehow need to tag the samples that get 'interrupted' so you can do the comparison between background and real sample under test.

[Edited on 6-9-2015 by m1tanker78]

smaerd - 9-6-2015 at 13:37

m1tanker78 - I probably could devise a way to do that using something like that. Maybe use an alternate arduino(if the problem is serial related) or even the rPi to count the digital pulses after the so called hard interrupt triggerr. I'm just abandoning the encoder-motor set up for now. I'm sure I'll find another use for the motor so it won't go to waste. Stepper will be the nicer solution in the long run.

I could make myself go mad trying to debug whatever is going on, but after a week or two of isolating the error the very few remaining options can be solved in a simple inexpensive way. Wereas the alternative debugging is likely to lead me to the same conclusion with more effort.

Maybe I'll swap out the motor on my rotary evaporator and microcontroller(or standalone circuit it) it so I can do actual RPM control.
 Pages:  1    3