next topic »

[on:]

My professor mentioned today that we are to think of designs for a cosmic ray detector. I think that he has some sought of telescope in mind.

The detector must log the time at which cosmic ray collisions occur, with a very high accuracy.

The event will be signalled by some output going high.

He mentioned that there would be many detectors placed apart, and this leads me to believe that the timing needs to be precise in relation to the other devices as well.

I would like to know if it is feasible, to construct a timer, using a simple microcontroller like a PIC or arduino, and perhaps a GPS receiver, and more accurate clock to keep track of the time.

Please can someone estimate:

a) at what time resolution and accuracy, two events on the same device can be related.

b) at what time resolution and accuracy, two events on different devices can be related.

[Reply #1 on:]

Please can someone estimate:

As a student, aren't those questions your responsibility?  Are you essentially asking us to help you cheat?

[Reply #2 on:]

tip: Uno runs  at 16 Mhz... which you should have looked up

[Reply #3 on:]

Yes, little hard to get 100nS resolution with 65nS clock cycles. Need something much faster.

[Reply #4 on:]

My god people are self righteous, I am a physics student, I don't think my professor even knows anything about embedded systems.

This is not a question posed to a class, but a project proposed by the professor, I am seeking guidance on the feasibility of it. Not asking anyone to do any work.

GPS is apparently deliberately skewed by 340ns for security reasons, but I suppose that this would be true for all the nodes in the sensor network.

The clock frequency of an arduino has not got much to do with the stability and precision of its ability to time btw. Crystal oscillator drift, and also the delays in signal processing was what I wanted to know more about.

[Reply #5 on:]

Yes, little hard to get 100nS resolution with 65nS clock cycles. Need something much faster.

Actually, with a 65ns clock cycle, timing resolution IS 65ns, provided one sample can be taken every clock cycle.

[Reply #6 on:]

My god people are self righteous

Yup.  That's me.  Self righteous to the core.

To ensure I cause you no further angst I will refrain from all further contact.  Good luck with your project.

[Reply #7 on:]

Given the fundamental 65nS cycle time of an Arduino you can never get precise 100nS timing. You could run the chip at 20MHz and use the capture facility of a hardware timer, as long as the events aren't too frequent so you have time to save the results.

______
Rob

[Reply #8 on:]

I don't think my professor even knows anything about embedded systems.

He must be a theoretical physicist. They're all thick as posts.

Please can someone estimate:

You're the physics student, right? Try these two questions:
1. what is the speed of light?
2. How far does a cosmic ray travel in 100ns?

Now you can answer your own two questions.

GPS is apparently deliberately skewed by 340ns

Which, if true, makes it totally useless for 100ns resolution, don'tcha think?

I'm not exactly a physics student but what I have read about physics experiments of the sort you've mentioned leads me to believe that in the realm of cosmic ray detection, 100ns is an eternity.

Pete

[Reply #9 on:]

Really, I haven't got a clue...  I have no idea how to keep dispersed systems in-sync.   But, I'm sure this has been done before, so you shouldn't have to "invent" something.   GPS might be fine, because it's relative skew that's important.   And, I assume they would all be close-enough to each other that they'd be using the same GPS satellite.

My guess is that it would be best to use "something else" for the critical timing.  Then, you can use the Arduino (or PIC, or laptop, or whatever) for control & data collection.  I'm assuming the data is not coming-in at a rate of 100nS, just that you have to make a 100nS measurement every once in awhile.   As an analogy, I've got an oscilloscope in front or me...  The data might be coming-in at a MHz (or kHz) rate, but I can only "see" it if I capture & hold it, or if it's repetative.   If I look at a CPU address or data line in real-time it just looks like a mess.  (Sometimes, it's still helpful to look at, because I can see if I'm not getting the full 5V, or I can see if it's "stuck" at 0V or 5V, or something like that...) 

If it helps, a "typical off-the-shelf" crystal is rated for accuracy/drift around 50-100ppm.   So, I would expect the Arduino to have accruacy & drift within that range. 

As a student, aren't those questions your responsibility?  Are you essentially asking us to help you cheat?

At the university level, "working together" and the use of outside resources & advice is generally encouraged! (Except on exams. )   At least, that's how it is in Science & Engineering,  here in the U.S.

[Reply #10 on:]

Yes, little hard to get 100nS resolution with 65nS clock cycles. Need something much faster.

Actually, with a 65ns clock cycle, timing resolution IS 65ns, provided one sample can be taken every clock cycle.

In theory yes,

In practice Well you want to detect the sample (with a interrupt on a timer ) at which stage the processor needs to save the current code pointer (waiting for timer overflow interrupt service fn to finish if necessary), then lookup and  call your interrupt service fn where you will at least save the timer value.... you've already rolled over quite a few (and varying) number of clock cycles. So you see these things will have a bearing  on the accuracy of your detection, much more so than physical properties of electronic components like stability ( for which you can usually get more stable components for a higher price)
 
you probably need to look for something 10 to 100 times  faster - ARM or Intel perhaps

[Reply #11 on:]

The detector must log the time at which cosmic ray collisions occur, with a very high accuracy.

He mentioned that there would be many detectors placed apart, and this leads me to believe that the timing needs to be precise in relation to the other devices as well.

You are introducing some very challenging timing requirements on the basis of what seem to be quite casual comments by your professor. What are the actual requirements, in terms of the accuracy of timing the events relative to other events at the same location, and at different locations?

[Reply #12 on:]

provided one sample can be taken every clock cycle.

Well, of course, there's the problem - most instructions take at least one cycle.

(BTW 1/16 000 000 = 62.5ns)

[Reply #13 on:]

Well, of course, there's the problem - most instructions take at least one cycle.

I was under the impression that the ALL take at least one cycle. Are there some that take less than one cycle?






Yeah, yeah, I know. I'm a smart ass sometimes.