A Teensy Challenge

Status
Not open for further replies.
J

JayRay

New member
Hi all, this is my first time to post on this forum and I will greatly appreciate any guidance offered. The project I'm working on is proprietary so I can't describe certain aspects, but the key challenge I face is finding a microcontroller(s) that can handle the following:

1) A total of 960 sensors, each with single digital detect/no detect output need to be monitored at 40us intervals. These are partitioned to 12 pcbs, 80 sensors each. The plan for the board is to capture the sensors' output in parallel, then use daisy-chained shift registers to serialize and provide to the mcu, one 80-sensor board at a time.
2) Of the total 960, a nominal worst case loading is about 10% or 100 sensors actually registering a detection over any 40us interval. Furthermore, typical loading condition is about 1%.
3) The environment involves significant dynamics; imu data must be updated a minimum of 100us, with high angle rates periodicaly involved,
4) Output is less demanding, and it's not really the focus at this point, but there will be occasional bursts of a couple vectors over approximately 30ms intervals, spaced by several seconds, but this data must be routed thru wireless with minimal latency. Also, the system must output 1 second heartbeat data.
5) A critical issue is of course the loading demand related to what's to be done with the data. What's to be done, basically, is some high resolution motion simulation over short time durations. I get to reduce usage of data for consecutive repeat registry for a specific sensor, which will cut down some considerable amount of sensor detections that need to be processed (tbd). Of course, they would still need to be touched... but I could provide the boards with discrete logic to "pre-sniff" whether any of its 80 sensors has registered a detect, if necessary. This could be checked before the whole board is polled; no detects at all and the board doesn't need to be read at all. It's not preferred because of the slight degradation to probality of detection, but would be acceptable.

My first question: can the teensy 3.6 handle this? I'm not sure how much of the 180 mHz teensy 3.6 I'll need but suspect even 1/4 of it's duty cycle will be adequate. But I'm not sure how much will be left after this level of IO. The input from just the sensor rate (without pre sniff, and excluding imu data) presents an apparent steady state demand of 24Mbits/sec. I've looked and found some good info on this site that seems to indicate it's plausible over short intervals, correct? And what about for steady state?

2nd question: Is there an obvious better way, given the limited information I've described here?

Again, much thanks for any feedback.

J
 
My first impression would be no, this is probably too much for a single Teensy 3.6.

Perhaps some incredibly cleaver and difficult design could make it all work on a single board, maybe by running both I2S channels in TDM mode. But even that would naturally give two shift registers of 256 bits each. While it may be possible with quite a lot of work, probably involving some logic in a CPLD, unless you have a tremendous amount of time (and skill with DMA and low-level programming), I wouldn't recommend going down that path.

I'd imagine the most practical approach would involve 4 or 6 Teensy 3.6 boards acquiring all those digital inputs using ordinary 30 MHz SPI and doing some pre-processing of the data. Perhaps they would transmit short messages (less than 8 bytes) on their serial ports at 2 or 3 Mbit/sec. Then you could use another Teensy 3.6 to receive all the messages every 40 us and do whatever motion analysis stuff you need.

You might also check the specs on whatever IMU you're using. Does it really have internal analog bandwidth and total latency necessary to give you meaningful data at 10 KHz sample rate? They're almost all based on similar MEMS technology involving oscillators in the dozens or hundreds of kHz, where changes in phase or frequency are demodulated and then low-pass filtered to produce a usable signal. Some have adjustable filters to let you trade off speed versus accuracy & range.
 
Your response is impressive because you've hit several key issues that track well with my thoughts over many weeks, in one simple reply. Very helpful.

I am a little disappointed, but not too surprised since it was being a little greedy to try and cram all into the single Teensy. I am not incredibly clever, don't have a tremendous amount of time or skill with DMA and low level programming. So I won't go down that path.

Prior to looking at the Teensy, I was also thinking of front end processing, maybe using a nano for each board, then using SPI to feed a Due, but I don't think the Due can handle even a reduced IO load. I would potentially lose data rate and incur higher latency from the sensors if I only alllowed a single 40us batch of detects to be sent every 240us per board (conservatively assuming 20us between SPI peripherals). That's probably ok as long as I get high probablity of detect over that 240us interval. Still require time alignment with imu based orientation data to within 50us but that's manageable. I don't see any easy way to put discrete logic on the boards to get a similar lower output rate directly to a single Teensy.

But now I'm thinking I could replace the Due in the above scheme with the central Teensy, in other words rather than go with the multiple Teensy configuration you suggest, it might be cheaper to go with a greater number of nanos if it has the horsepower... any thoughts?

As regards the imu data, yes those are real issues that need consideration. Data fusion algorithms, Kalman filtering, and to a lesser extent nav data are where most of my experience is at so hopefully I won't stumble there. I had my eye on the Invensense 20649, but I noticed the Prop shield on this site has Freescale devices that, while probably not the longterm solution, would be a nice stand in and convenient first step in the development process for me to advance my understanding of the problem. This should take me a long ways. It has more bells and whistles than I need but even some of that also can be used in this project. I'm not sure but looks like the shield is Teensy 3.6 friendly.

Thanks again and any feedback is appreciated.
 
This is a bit out of my league, but I'm curious: Would it be possible to read the data coming from the shift registers in parallel? That is, connect the first shift register to PTA0, the next to PTA1, ..., PTA11 on the K66 (if the Teeny board allows) and read them with a single instruction (i.e. a 32 bit read from Port A), then do a binary AND with 0xfff to check for hits?

Edit: Fixed a number.
 
Last edited:
Are these digital sensors (1 bit each) or ADC (1-2bytes?)
If its binary you would need "1 / (0.00004 / 960)" = 24Mhz minimum just to move the data.
If its ADC its much much harder lol.

Edit.. Fixed math.
 
Last edited:
Loraty, yes in principle it's possible but in this case there are board layout restrictions and providing the parallel inputs is a problem. It's hard to explain everything in these posts but thanks for the suggestion.
 
Status
Not open for further replies.
Back
Top