No Atmel AVR experience... what's the right device for this project?

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My research lab is developing a multi-sensor capture device. Sensors involved include IMU, GPS, RADAR, cameras, etc.

 

We will have a high-quality 10MHz OCXO primarily used as the sample clock for our GPS RF front-end. Ideally, we'd want all of our various sensors either directly triggered off of or synchronized with a common clock. It makes sense, in my mind, if that common clock were the 10MHz OCXO that will be installed in any case.

 

Both our IMU and RADAR want PPS (pulse-per-second) signals to synchronize their internal clocks to. The cameras want each frame capture to be directly triggered (we want to trigger anywhere between 10-30 Hz). And our GPS front-end, of course, needs the full-rate 10MHz clock. So, I'm thinking that I want a micro-controller directly driven by the 10MHz OCXO as well. I'd then like the micro-controller to drive the PPS and 10-30Hz camera triggers based on this reference clock. I'd also like to be able to output a "trigger log" over a serial interface which associates each PPS and camera trigger with a timestamp that can be read by a "PC computer" (Intel NUC, as of now). My GPS receiver is running on the Intel NUC and I'd want to be able to feed GPS time from the NUC to the microcontroller in order to align the PPS signal to the integer second.

 

I can handle the required programming. What I'm overwhelmed by is the wide selection of Atmel microcontrollers. I also would prefer to work with a "development kit" since our project will only involve 2 or 3 units total and designing a custom board for this application isn't worth it.

 

Would someone help by suggesting a good Atmel product for this that, at least, (1) can be driven by an external 10MHz clock and (2) is "rapid prototyping" friendly?

 

Thanks in advance!

Last Edited: Wed. Aug 9, 2017 - 05:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

HI,

 

I'm sure you get a lot of replies from folks more experienced that I, however here are my thoughts:

 

I am currently using an Arduino pro mini (Atmel 328P) and coming from Microchip products I was impressed with the built in hardware timing capability.

 

I think for your application the pro mini or similar board could meet your requirements.  At least I think it is a good place to start.  As a programmer, you understand that an initial task is to allocate µP resources to tasks.  If the µP you start with needs additional resources you just pick a more powerful board.

 

I didn't say it above, but the arduino platform in most cases is simply a µP breakout board. They are conceptually to "development boards".

 

I the program the arduino in C using Atmel Studio 7.   I doubt the Arduino IDE will let you control the resources you will need.

 

John

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It sounds like you want to directly receive and process GPS signals. That is suggested by:

 

OCXO primarily used as the sample clock for our GPS RF front-end

That is a very non-trivial undertaking. Keeping up with the GPS data stream without interruption for your other tasks will also be a major challenge. I would opt for a GPS receiver that outputs ASCII NMEA data strings (unless this is what you already mean by "GPS RF front-end").

 

Jim 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A separate GPS RF front-end is being driven by the 10MHz OXCO. I only mentioned it because it is the reason why we'll have a quality 10MHz clock available in the first place. I'm wanting to additionally drive a micro-controller with the 10MHz clock that I'll already have. The GPS aspect is well in-hand (that's what our lab specializes in). I'm searching for a micro-controller that I drive w/ the same 10MHz so I can precisely time-stamp all of our various sensor measurements to a single clock source.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Welcome to the Forum.

 

Wow, sounds like a cool project.

 

Atmel, (now Microchip), does have development boards.  But as already mentioned the Arduino lineup are essentially small development boards with mainstream Atmel AVR processors.  They come with a on board power supply, on board USART to USB bridge, on board Xtal, on board LED, I/O pin breakouts, and may have an on board on/off switch, Reset switch, 3V/5V level switch, etc.

I have some Arduino Uno's and some Arduino Nanos.  I've very rarely used the Arduino IDE, I generally program them in Basic, although most of the Forum generally uses C or ASM.

There is a wide range in prices, I generally order them from BangGood Electronics if I can wait for their arrival, (Nano's < $3 USD), although it sounds like price is not an issue for your project.

 

Jim mentioned the GPS, for a quantity of three final units why in the world would you want to design / integrate / use a raw GPS front end!  Getting that up and running is in itself a significant project.  If you aren't experienced in RF design, and have a good RF bench, then it is truly a shot in the dark as to whether your GPS front end will work or not, on version 1, or 2 , or 3...  There are many small OEM GPS modules available, have a look at Spark Fun Electronics GPS page for a starting point.

 

Perhaps I am missing a subtle, (or not so subtle!), point, but why are you trying to "synchronize" the GPS PPS, Camera Frame, and other sensors to the 10 MHz "Master Clock"?  I think it is time to rethink the overall project timing from "the big picture" perspective.

 

A 10 MHz clock will put out pulses every 0.1 uSec.  At 10 Hz camera frame rate one is capturing an image once every 100,000 uSec.  Does "synchronizing" to 0.1 uSec really make a difference?  What, BTW, was the +/- jitter time internal to the camera's obtaining the image?  Is the pulse the capture it now signal, or the send me the current image in the sensor array signal?

 

Likewise, if the data is being collected and shipped up a serial interface that shipment takes mSec of time, (perhaps, depending upon the baud rate, data packet format, CRC, error detection and/or correction info, etc.).

 

Likewise, once can certainly feed an external clock signal into most of the common AVR's and set their "Fuses" to run on the external clock signal, instead of their internal RC OSC, or attached external Xtal, but 10 MHz seems pretty slow these days, for a data collection, time stamper, buffer, and exporter, of multiple data signals.  It also may or may not be a USART friendly clock frequency, depending upon the baud rate selected.

 

And, once more back to the GPS units, they output a 1 PPS signal, if they have that in their firmware.  The micro you propose as the Master doesn't send a 1 PPS signal to the GPS, at least if you are using a pre-fab'd GPS module.

 

I'd suggest letting the GPS module run on its own, and depending upon the module you might get 1/Sec common data sentences, or even a 10 Hz data update of user selected data sentences.  Read those and your IMU and other sensor data into the micro, letting the micro buffer the data, form the data packets, with/without error detection/correction, and timestamp them, and send them on their way up the data processing chain to the "PC".

 

I hope the camera has its own data path to the "PC".  I would not read, buffer, packetize, and send on the image data through the micro while also doing the other tasks.  It isn't necessary to do so, and would require a significant portion of your micro's processing power and memory.  That said, the micro could certainly trigger the frame capture and auto-upload.  It you really want the camera image data, full image, at 30 FPS, for route through the micro then that will be a significant factor in micro selection, memory size, and clock speed.  Know that most AVR's run at 16 or 20 MHz Max clock frequency, while the Xmega's can run in spec at 32 MHz, (and have a priority interrupt controller, and DMA, etc., missing from the Tiny and Mega chips).

 

Sounds like a great project, but some more explanation of the source signals and what happens to them would be helpful in order to select a micro.

 

Last comment, (for now, anyway), is a general concept in new project prototyping is to select a "large" micro for the project's development, (Large can mean large memory, fast processor, lots of I/O pins, etc.).  Once the project works one can scale it back if their goal is to sell 1000's of units, otherwise call it done and move on.  Nobody wants to be part way through their project's development and suddenly find that they need more memory, more pins, more speed, etc.

 

OK, one more comment.  If the master system trigger signal is a 1 PPS signal, then any micro can easily generate that, with negligible jitter if the Timer/Counter module generates it, or with a very small amount of jitter if the micro generates the pulse itself.  Running the micro at 32 MHz, (or overclocking the Xmega a bit...), will likely have less jitter in the 1 PPS master reference signal that running the micro at 10 MHz.

 

JC

 

Darn, I left my computer for a bit to run an EMS call, and missed the OP's post above.

So ignore the GPS comments, but the data collection comments still stand true.

0.1 uSec synchronization of the other sensors sounds like an odd system requirement, but if it exists so be it.

You can certainly, as already mentioned, clock the mainstream AVR's with your external 10 MHz clock.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think you really need to clock everything from the 10MHz reference. The short term stability of the average crystal oscillator is quite good. I did a project where i had a number of nodes connected by uhf wireless modems and needed to schedule a TDMA based method. I only required millisecond precision so i phase locked the 1pps signal in software. That way each node was synchronised within 1ms of each other. The actual jitter was around 10us. An arduino is perfectly adequate for this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I said "The GPS aspect is well in-hand (that's what our lab specializes in)"... more specifically, our GPS software defined receiver is most notably running on the International Space Station. Our custom GPS RF front-end has been sold to more than one company for various projects. In other words, the GPS aspect is well in-hand.

 

As to why I am wanting to synchronize several sensors to a common clock? Because they either use the same clock ... or they don't use the same clock. If they don't use the same clock then I would need to know how each of the individual clocks relate to one another. I would have to measure and estimate their relative alignments and drifts. Using different clocks for multiple sensors doesn't make things easier in the end; it makes things harder.

 

With "multi-sensor" applications, you need to know when a measurement is taken from one sensor with respect to all other sensors. That is, you need timestamps with respect to a common clock. One way that people do this is by NTP or PTP synchronization of their various devices to UTC... but that requires that all of your various sensors support NTP/PTP time-synchronization. In that scenario, your common clock is UTC. Another way to do this is by driving everything from a common clock oscillator and then frequency dividing/multiplying to produce all the triggers and pulses you need for your various applications. The point isn't that I need a camera trigger accurate to 0.1 uSec (because I don't) ... it's that it's a whole lot easier to relate multiple sensor measurements when they are all driven by the same "master clock".

 

When I use a "master clock" then I will know, for example, that the 1st camera frame corresponds to the 1st PPS pulse and the 1st GPS sample. And that the 31st camera frame corresponds with the 2nd PPS pulse and the 10,000,001th GPS sample. I assure you that this makes the application tremendously easier to work with.

 

Also, the micro-controller has nothing to do with the GPS sampling or signal processing, with camera image capture, with radar capture, or any other data capture. The only purpose of the micro-controller is as a "configurable trigger source"... as of now, I require PPS and a 30Hz trigger. I would like to be able to easily produce other trigger rates. The desire for flexibility is why I'm thinking of using a micro-controller here and not discrete components.

 

Does that clarify what I want the micro-controller to be? I just want it to produce configurable triggers on GPIO and be driven by a 10MHz clock (or, at least, have the timer section driven by the 10MHz clock).

Last Edited: Wed. Aug 9, 2017 - 11:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 I require PPS and a 30Hz trigger

Got it.

That helps a lot.

 

Any AVR can do that.

 

Grab an Arduino Nano and have at it.

 

That said, I think we are still not on the same page as to why it is important to synch everything to a single 10 MHz clock source, IF the true "Master System Synch Signals" are the 1 PPS signal and the 30 Hz signal.

The microcontroller clock that is generating the 1 PPS and 30 Hz pulses would still seem to me to be totally independent of the 10 MHz clock source running the GPS hardware.

The micro generating the 1 PPS and 30 Hz signals is the Master for the overall system timing.

The GPS is just one of several sensors, and it does its thing, (GPS in this case), and reports data when instructed to.

 

Note that the 1 PPS and the (10 - ) 30 Hz signal ARE automatically synched as one micro is generating them, such as described below.

 

That said, I don't want to seem argumentative, it is your call if everything is "synched" to one 10 MHz clock source or not.

 

And, again, generating the two trigger signals is a simple project, especially since it sounds like the micro that does this is not actually handling any of the data itself.

 

The next question to be asked is how "accurate" must the 1 PPS and the (10 - ) 30 Hz signal be?

The reason being, of course, that if you want extremely accurate, with  extremely low jitter, (only the jitter of the 10 MHz clock, essentially, well almost), then obviously one does the dividers in hardware.

BUT, as you mentioned, that doesn't give one an easily adjustable camera frame rate, (the 10-30 Hz signal).

 

One approach to your two trigger pulse generator project would be to take your Arduino Nano board and program one of the timer counters in CTC mode to generate an interrupt once every 1 mSec.

 

In the ISR you maintain two counters.

One counter counts up to 999 or 1000 (picket fence, special case problem, does counter roll over to 0 or 1,,,, etc.).

Anyway, ignoring the end point, you have a counter that fires once every 1 second.

Hit 1 second, set a pin high, roll over the counter.

At the start of the ISR you set both trigger pins low.

 

Second counter counts up to X mSec for your 10 - 30 Hz camera trigger.

Same as above, hit the threshold, set an output pin high, roll over the counter.

 

If the ISR clears both of these pins, (regardless of whether or not they are high), at the start of the ISR, then each pulse will be 1 ISR interval high, i.e. 1 mSec in this example.

IF you set a pin on the last ISR firing, it will be automatically cleared on the next ISR firing.

 

Note:

Often one tries to simply set a flag in the ISR and do the processing in the Main Loop.

For this simple task it doesn't matter if you take the time to set and clear a few I/O pins within the ISR.

 

There will be some inherent jitter, in 0.1 uSec's units, (10 MHz clock), based upon the current instruction in Main being executed when the ISR fires.

The ISR will take over following completion of the current instruction being executed.

 

There is a fixed delay from triggering the ISR until the ISR code is executed, for the various register pushes upon ISR entry.

That is fixed, so immaterial for a sequential pulse train system.

There is some slight jitter in exactly how many micro instructions were executed to get to the set a pin instruction, based upon the preceding code within the ISR and the exact path it took.

 

(That is why running an Xmega at 32 MHz will decrease the "jitter", as +/- a few clock cycles at 32 MHz, (of faster), is less significant than +/- a few clock cycles at 10 MHz, which is one of the reasons to synchronize the overall project against this micro's Master trigger signals, but (perhaps) not to run each sub-system off the same (slow) 10 MHz clock source.)

 

The Main Loop, by the way, can either be empty for testing fixed pulses at 1 Hz and 30 Hz, or you could easily add an LCD and a couple of push buttons to incr / decr the 30 Hz signal.

Likewise, if this Master trigger generator micro is feeding timestamp signals to the PC, then one would likely set a flag in the ISR and transmit the timestamp from the Main Loop.

 

JC 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just pull the crystal from an Arduino (or clone) board, change the boards.txt crystal freq to 10MHz and recompile the bootloader. All from your same 10MHz source.
With the GNSS boards i've used, they give a 1pps signal and I sync to that and generate my timing from that to a fair degree of precision.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Excellent answer. Thanks for the detail.
 

I don't know how to explain why a common clock source is beneficial to me much beyond my previous post. I'll add that our GPS receiver is completely unlike any off-the-shelf "black box" receiver. It is our own; it is implemented 100% in software; and the "receiver time" is the time to which all of our processing is referenced. The "receiver time" starts at 0.0 sec at receiver turn on which corresponds exactly to the leading edge of the 1st GPS sample. A receiver time of 1.0 sec corresponds exactly to the leading edge of the 10,000,001th sample. And so on. Since the receiver time-base directly corresponds to a sample count then it is directly tied to the 10 MHz oscillator without discontinuity or drift. If our GPS receiver is configured to output measurements at a 20Hz rate then it will do so with respect to this "receiver time" and _not_ with respect to GPS system time. So, I'll get my GPS measurements at time 0.00, 0.05, 0.10, 0.15 s "receiver time".

 

Two different clocks means two different time bases. They will run at different rates and turn-on at different times. If I use two different clocks then I have to do something to synchronize the two or monitor one with respect to the other. I have to know which GPS sample was being captured when a certain IMU measurement was captured, for example.

 

Any application that requires time synchronization always _tries_ to reference to some common clock. As I said, some use NTP to synchronize all their devices to GPS System Time. This gives you ~1 msec synchronization. This also requires all of your devices to support NTP. And, frankly, any application that requires time synchronization between multiple devices _wishes_ they could just drive everything off a single clock... and they jump through a lot of hoops to get as close to that ideal as possible. I want to use a common clock because using multiple clocks makes the task much more difficult and because using a common clock is the ideal ... so why wouldn't I use the ideal?

 

I understand that 10MHz is "slow" by uP standards but the jitter you're talking about is perfectly acceptable for our applications. What I want is <100 milliseconds.

 

How would you change your recommendations if I wanted to also receive trigger inputs and time-stamp them with respect to the same time-base? Is there a counter driven by the 10MHz external clock that I can get the value of both when I'm in the ISR for trigger as well as within an ISR from an "input trigger"? Would this just be an 8-bit counter or can I get something on the order of 32-bit?

Last Edited: Thu. Aug 10, 2017 - 04:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, the key point that I really wanted to clarify (I suppose the answer is obvious to everyone but me)... I can drive any AVR with a 10MHz clock? Or with any arbitrary clock rate (within some range, of course)?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The datasheet details the range of external clock frequencies. At 5V the mega328 is good for 20MHz if my memory serves correct. Minimum is DC, but not much gets done. So, 10MHz is in the sweet spot. You have a choice of internal counter/timers of 8 or 16bit clocked from the system clock, via the prescaler or from an external clock not related to the system clock.
What precision of time stamp do you want?