how many serial tx rx inputs

Status
Not open for further replies.

ben10teensy

Well-known member
I have a 9dof IMU sensors working on i2c to microcontrollers(MC), each IMU will have its own MC. They export the data to serial rx tx. My question is if i have 10 or 15 IMUs with about 3 feet of cable to the main MC could i have one teensy gather all this information and have that one organize the data and through serial or should i use i2c
 
e organize the data and through serial or should i use i2c
9 Microprocessors unit (MCU)
one IMU sensor per MCU. Each sensor uses I2C for the MCU interface. This needs to be 6 inches or so without special design work. I2C doesn't like much wire. And you'll probably need low I2C clock speed.

each MCU exports sensor data [to one main MCU]

How to get 9 MCUs to send to one kmain MCU. That's the tricky part.
RS485?
SPI, where the main MCU is the SPI master and it polls the 9 MCUs as SPI slaves, each with a separate chip select bit?
A second I2C port for inter-MCU, separate than I2C for IMUs?

Simpler to use one MCU interfaced to all 9 IMUs.
 
I misread The OPs message. I understood 3ft from MCU to MCU times 10 ;)

I think it's time for the OP to post some moe details. What MCUs, what IMU ? What exactly is the overall purpose of the project. Why 9 IMUs ?

I agree, it's much simpler to use one MCU to read all the sensors.
 
Ok Thanks for the replies.
To my understanding each imu has to have its own mcu because of the math done to fuse the 9dof. Plus it's easier for me to use the fusion code already out there.
The reason is for motion capture.
i have one almost completed using a gy-85 sensor and i have a arduino uno because my teensy 3 got damaged but will be returning to teensy 3.1
 
So 3 feet of cable is to have a little extra in between. I would like to eventually go wireless at every imu but wire is in my current budget
 
I'd consider going to RS485 just for interference resistance. One master, lots of slaves. Half-duplex at 1+MBPS.

Since the datagrams are well defined, I'd further suggest the use of the Easy Transfer library by Bill Porter. Makes transfer super easy.

Lastly, Paul has included a method of toggling the RS485 transmit/receive pins right inside the Teensy IDE to allow pins to remain 'high' just long enough to empty the serial buffer.
 
Well, that was my original thinking, but it depends on the physical bus topology. It may not be practical to daisy- chain the 10MCUs, which is what one would normally do with a RS485 or I2C bus system.

The question of physical topology still remains to be answered to be able to provide a practical answer. Perhaps it would help to find what kind of motion is to be captured!
 
Even though RS485 is supposed to be connected only in a daisy chain manner, with only 30 feet of wire at reasonable baud rates (up to 57600 or even 115200), you can wire it in a star or other topology. The signal reflections just aren't a big deal with such short wires.

Some RS485 transceiver chips have a slew rate limiting feature. They're easy to spot, because they're the ones rated for 250 kbps maximum speed. Those types have much lower signal reflections, so it's best to buy those if you're going to wire things without a strict daisy chain approach.
 
Ok so to understand it correctly i would have to Daisy chain or could i use a device or even just the teensy to be the hub recieving all the inputs.
Because of where the devices will be i wouldn't want to have to wire them in chain, example arm, shoulder back, arm hand, lower body. ...
 
As Paul mentioned, if you want to use a star topology, you likely need to use a slew limited rs 485 chip. Still plenty fast at 250kbps.

I'd consider making use of all three serial ports on the teensy nonetheless. Small upcharge for two exta rs485 chips for the master teensy but you can then use the buffers on all three channels to transmit a request and then receive it. Increases your throughout and gives your master more time per slave to send a TX request and then receive it.

For example, one channel for the left side, one for the right, one for the head and torso.

I've had good luck with the various flavors of Intersil chips. I suggest in particular to look for models that have a high esd rating, ie 16.5kV is not uncommon. Makes for a happier life for the teensy in case all that dancing leads to static electricity buildup. Your wiring harness would have 4 wires, two for data, one GND, and one power. Ideally, the power wire would be protected at each teensy with a tvs or Zener to limit the voltage to less than 5v to keep static at bay.
 
Last edited:
Thanks, do you think 3 of these chips would be the way to go?
https://www.sparkfun.com/products/10124
 
Last edited:
This one would probably be best.

http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&keywords=MAX3430EPA+-ND

There are many others in surface mount packages. This is the only DIP8 one I could find that's slew rate limited and 3V power.

You can also use a 5V chip, like this: (much less expensive)

http://www.digikey.com/product-detail/en/MAX487CPA+/MAX487CPA+-ND

Just power it from 5V instead of 3.3V. It can use 3.3V signals from Teensy (logic high is anything over 2.0 volts) and Teensy 3.1 is 5V tolerant, so the 5V output this sends is ok to connect to the RX1 pin on Teensy 3.1. Just don't use a Teensy 3.0, because only 3.1 is 5V tolerant.
 
Hey Paul
do you think i could do the math for fusion of more than one imu on the teensy 3.1 ? That way i wouldn't have to have a board per imu
 
As I recall, FreeIMU was able to run at least 1000 times per second. Much of the time appeared to be waiting for the I2C communication.

You could probably investigate this question by adding code like this into your project at strategic locations.

Code:
    Serial.println(micros());

Or perhaps like this:

Code:
elapsedMicros my_usec;

void loop() {
    get_data_from_sensor();
    Serial.println(my_usec);
    do_sendor_fusion_math();
    Serial.println(my_usec);
}

By watching the numbers, you can discover how much time your code is actually taking to acquire the data and to do the math.

I hope you'll share your findings here, so others might be able to find the info?
 
Well now thinking about it and the distance from i2c device to another it wouldn't be possible. Being that arm to hand cabling would be about 2feet

Here is the beginnings of the motion capture using pot sensors working in 3ds max with no coding on 3dsmax side. Just the teensy code

http://youtu.be/90VFtk6psoA
 
Still wouldn't hurt to do a little investigation into the number of microseconds your code is spending acquiring the raw data and the time it takes to compute the final results....
 
Hey thanks, i really appreciate your help. I'm just getting into this type of science and teensy has been a great product.
 
Well now thinking about it and the distance from i2c device to another it wouldn't be possible. Being that arm to hand cabling would be about 2feet

Here is the beginnings of the motion capture using pot sensors working in 3ds max with no coding on 3dsmax side. Just the teensy code

http://youtu.be/90VFtk6psoA

Very cool project! I've seen somewhat similar things done with Blender. Not quite as ambitios though.

Another approach to reduce auxiliary hardware, e.g. RS485 transceiver chips and the Number of MCUs needed is to dedicate one MCU to each limb. Then connect the IMUs for that limb to the MCU per I2C. The nice thing with I2C is that it is implemented in Hardware on the MCU and on the IMU. It does not require any local processing power at the IMU and no to little overhead on the MCU. 3-4 ft of I2C cable might not really be so bad in my experience and should work even at 100KHz. In my lighting system http://trippylighting.comI use I2C to talk to the LED drivers on more than 15 ft of I2C cable at 100KHz bus speed. Most IMUs I've seen work at a max of 400KHz. Might be worth experimenting with it for this project.
The other nice thing with I2C is that you don't have to implement your own protocol. RS485 is an electrical specification but not a protocol. You'd have to take care of that yourself ;-)

Once you have broken up your project into smaller sub segments and start processing the Sensor Fusion on a per-limb basis, you can then communicate the results to the master CPU. As the data is pre-processed, again, you could possibly also use I2C Because your actual bus length does not have to cover the whole project down into the lims but "just" an entire limb. Not only have you reduced the actual bus length, but also the number of devices on the bus.
You'd also not be limited to the max I2C bus frequency of the IMU because you'd be communicating from MCU to MCU.

If you need a higher data transfer rate between the MCUs than the the Teensy can easily get to 1MHz I2C bus speed (and much higher actually). Then you will need a little additional hardware in the form of I2C bus buffers ( 1 per MCU ) such as the PCA9600 ( works up to 1MHz). The differnce to RS485 is that still you don't need to implemet your own protocol. But I would doubt that higher bus frequency would be would be necessary. Just trying to show you that you've got good options and a way to reduce the complexity of your project.
 
Last edited:
Hey guys so ive read over your great ideas on how to do this but Im not sure about some things.
1. If I have all 10 devices sending x, y, z rotations through rs485, are the sensors just spitting out the values and the master is catching and organizing or because it is half duplex will it lose any data?
2. Could I just use a mix of software serial and hardware serial and receive all the data directly.

I only need it to be updating about 50 to 100 times per second.
more would just be extra
 
1. If I have all 10 devices sending x, y, z rotations through rs485, are the sensors just spitting out the values and the master is catching and organizing or because it is half duplex will it lose any data?

If they just turn on their RS-485 driver enable pins without any timing sync method, eventually 2 or more will almost certainly attempt to transmit at the same time, resulting in a corrupted signal and data loss.

2. Could I just use a mix of software serial and hardware serial and receive all the data directly.

If the sensors only transmit, and the master only listens, and there's no sync mechanism to prevent 2 from transmitting simultaneously, no amount of trickery using software serial, hardware serial or other approaches will recover the lost data. When 2 transmit at the same moment, a corrupted signal will arrive, so you're going to have data loss.

The most common approach in these system is a query-response protocol, where the master transmits a query to one sensor, which then replies. Then the master transmits the query to the next sensor, and so on. All sensors hear all the queries, and when one sensor transmits, the others all hear it, so careful design of the protocol is needed so the queries are all unique and can never accidentally occur in the sensor data.

The other less common approach is called token passing. In such a system, each sensor listens for either a query from the master, or the data from the previous sensor. In normal operation, the sensors all transmit one after the next. Some token passing protocols have more complexity in the sensors, to automatically learn which sensor is the previous one, so you get back-to-back transmissions even when one goes offline. Well, except for occasional polling from the master to check if it has returned, and some strategy for it to not conflict with the next one that as learned it's missing, and.....

Usually the query-response approach is used, because it's much simpler, even though it does come with the cost of extra communication from the master to cause each sensor to transmit its data. The senors simply listen, and the master needs only a basic timeout when it tries to query a sensor that's offline. Usually masters are written to maintain a list of online sensors, so they can retry offline addresses infrequently, so avoid slowing down communication with the ones that are responding. Sensors usually have some design spec for a (hopefully short) maximum response time, which allows the master to know how long it must wait before concluding a sensor is offline.

Also, with RS-485, it's advisable to always add a brief delay before turning on the transmitter. Sensors should delay slightly before replying, and the master should delay briefly before sending another query. Those delays allow time for the other transmitter to turn off, before you turn yours on to transmit. With Serial1.transmitterEnable(), Teensy will usually control the DE pin with excellent timing. But if you later add a regular Arduino or other board into the mix, it might not be so fast. The dead time, which is sometimes called "turn around time" also allows for RS-485 repeaters to be used to extend the distance or solve star/stub cable routing (not all in a pure daisy-chain) problems.
 
Last edited:
Thanks for your reply.
This was my design before your explanation on
rs485. Being that I don't know much about protocols
would this work? Teensy to 3 serial.jpg
 
Last edited:
would this work?

In concept, yes it should work fine.

Of course, the final result depends on numerous small details which aren't described in such a simple diagram.

In particular, if you have a long distance between boards, RS-485 signals are the most reliable way to communicate over long wires.
 
I think based on what already has been discussed the topology shown in that diagram does not make any sense.
It would be inefficient to wire something like that if it's used for motion capture on a limbed being such as a human.

That's why I described the approach in my last post. rs485 is NOT a protocol and Paul's description is very detailed what would be involved in developing ones own. That is clearly above the skill level of the OP.

Also for the distances and refresh rates r485 is rather overkill.
 
Status
Not open for further replies.
Back
Top