SparkFun Forums

[SOI_Sentinel]

Well, this is a little project of mine to complement the ongoing (but slow going) RC project.

I've had several thoughts on how to build a gyro-less IMU unit, and the Motorola accelerometers let me focus the design down to two chips. This can then be small enough for ultralight design. Resolution of the sensor goes up (and top rotation measurement down) as the sensors are separated. The exact same thing can be done with Analog sensors, with tradeoffs. You need to be able to position three 2D sensors, requiring two riser boards. You can thereby vary sensitivity on specific axes by changing separation distances. So, more space, less noise, more flexibility.

I'm trying for a very high density layout combining the 5V PIC18F2580 and two MMA7260Q's. Primary connection is through the CAN interface. So, I have 6 of the 8 ADC inputs accounted for. I will be changing resolution on the fly (4 digital outputs), but I'm not certain if I'll be using the shutdown pins on the accelerometers.

Now, the layout issues I'm seeing. I'd like to use the Vref+ and Vref- inputs to adjust the ADC to read the accelerometers full scale. This drops me to exactly the 6 ADC inputs I'd have. Now we see some layout issues. I can route 3 of the ADC lines around the Vref inputs to get a good analog connection. The second one, however, will have to cross or go around the CAN interface. Given that this interface will be running up to 1Mbps, this might cause problems . Note, the layout of this is a small board with the accelerometers at the extreme far ends and the CAN and PIC located near the middle (shaped like a popsicle stick).

Power to each component will be provided by an LDO in the current scheme, but that may change.

So, I'm trying to think of different options. I'd like to keep additional components to an absolute minimum. I could use opamps to shift and amplify the accelerometers, freeing up two more ADC lines so I don't have to go into the 2 ADC lines near the CAN interface. Motorola shows the accelerometers pretty much driving the ADC lines directly, but I'm not so sure that'll work well. A second option would be to use one or two external ADCs. Again, more parts and may STILL need op amp buffers. Depending on what I can get out for my designs, I might still need this if I need more than 10 bits of resolution. Third is moving to an external SPI CAN interface, again another chip and then I would have to chose a different (and possibly smaller yet) PIC.

I don't think running the PIC at 3.3V is viable as the CAN interface needs 5V I/O. I might move up to a 44 pin QFN (8mm a side vs 6mm a side), but I don't know right now. And I'm TRYING not to go to a four layer board. I'm still battling it out with learning Eagle, as I gave up and went back to variable RC aircraft wing design in Solidworks for the summer.

I'm looking for comments and opinions

[pittuck]

Now, the layout issues I'm seeing. I'd like to use the Vref+ and Vref- inputs to adjust the ADC to read the accelerometers full scale. This drops me to exactly the 6 ADC inputs I'd have. Now we see some layout issues. I can route 3 of the ADC lines around the Vref inputs to get a good analog connection. The second one, however, will have to cross or go around the CAN interface. Given that this interface will be running up to 1Mbps, this might cause problems . Note, the layout of this is a small board with the accelerometers at the extreme far ends and the CAN and PIC located near the middle (shaped like a popsicle stick).

...


I don't think running the PIC at 3.3V is viable as the CAN interface needs 5V I/O. I might move up to a 44 pin QFN (8mm a side vs 6mm a side), but I don't know right now. And I'm TRYING not to go to a four layer board. I'm still battling it out with learning Eagle, as I gave up and went back to variable RC aircraft wing design in Solidworks for the summer.

Humm, can u get interface IC's for the CAN bus?

I know maxim do them, it will allow you to run the sensor side at 3.3V with a 5V bus output.

something like http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2389/ln/ should do... 2Mbps speed will be enough for CAN. You might want to get a couple and test the setup before production.

Whats the output interface? Ultimately a Serial Input into a pc?

[jayjay]

Why CAN for a local interconnect? Why not LIN? or 1-Wire? iirc Dallas has a quad ADC 1-Wire chip (DS2450), 3 inputs can be used for X,Y,Z and configure the unused ADC as a GPIO to control the sleep. I am sure there are other simpler bus technologies that might ease the development. Of course, if you already done CAN stuff and very comfortable with it, then it may be a good choice

Good luck with your experiments

Cheers
Jay

[SOI_Sentinel]

Hmmm... maybe. I also need to review the external CAN transciever specs for Microchip, as it may be 5V tolerant. I already have some Microchip MCP 2551's to act as the physical layer interface. I was hoping to use the onboard CAN state machine of these, since adding something like the MCP2515 would add to my board space and use more IO with minimal advantage to a single PIC solution. Since the accelerometers swing from 0.45V to 2.8V in all modes, even running the PIC at 3.3V won't be enoughfor full resolution. I'll still need to either shift the voltage via op-amps or use the Vrefs.

Ultimate output is onto the CAN bus backbone of a digital vehicle control system (both full size and RC). CAN is complex compared to other protocols, but when you're driving data past motors and RF devices, it's hard to beat. It's being set up as a (hopefully) masterless network where each module takes and sends its data on the backbone as need be, so I can add and subtract modules without TOO much reprogramming

[read]

What is a proxy chain?
A Proxy chain is a connection of 2 or more proxy servers. ProxyWay allows to work with any Internet service through a proxy chain of SOCKS or HTTP proxies. Using the program you can create proxy services (cascades/chains) with any number of proxy servers (supports HTTP, HTTPS, SOCKS4 and SOCKS5) to provide IP address security and tunnel Internet activity through proxy servers.

http://www.socksproxylist.com