Which embedded system would you use?

Since the distances are that short, have you looked at for instance PCI Express ? This is of course point to point, but at x1, the cable consumption would not be that bad.

Are all data actually used in real time (e.g. in a PID controller) or is most used for later analysis, in which case it would make sense to collect a few samples and send it in a single longer message.

If there are a large number of nodes physically close to each other, but far away from the master controller, using direct wire connection to concentrators near the nodes and then use some CAN/Ethernet protocol to the master controller.

I guess you also need some clock distribution system, so having direct wire connections between the nodes and concentrator is not that bad idea.

As you said EtherCat might be an option even direct connection to each node, but the total cost might be quite high.

Should be fine in either case. Even real time PID controller can adjust with a few delayed samples.

That's why I suggested data collection agents between master and slaves. The agents collect and time stamp the data before following to the master. The system would have to time-sync them and/or keep track of time differences. Several samples can be packed in a single packet before transmission.

Full speed USB is cheap and good enough for this.

Maybe you should define the requirements in more detail.

4-5 sensors at 2ksps don't amount to 50-100 Mbps in my book, and 170us latency are easily doable with both CAN and (raw) ethernet. In fact, both proposals have headroom against these specs. What is it that I am missing?

For low latency communication with high bandwidth, you could look into the various technologies used for SAN storage. They push hard to optimize those two corners. The Linux driver sources can show you how to talk to a particular chip in your own environment.

Best regards

I know you were wanting to brainstorm alternatives, but, it seems your sense about ethercat is not at all unreasonable. Twincat/EtherCAT (or even Power over EthercCAT) don't seem to have downsides, it 'may' be overkill, and there probably are alternatives that would work, but I think your first choice here certainly hasn't been convincingly shot down.

found this(perhaps you know of it already?);

Sorry got very busy on past few days.. back to the discussion. Concentrators are a reasonable idea.. but i am trying to avoid intermediate systems due to latency between some signal and systems response. Thats very critical. Something different from star or Bus is not acceptable due the cable numbers.. and thats another critical part. Just a better representation of the complexity of the system. Somthing comaprable would be this:

but with more complex sensores, and with more flexibility in general (theis system in specifc, uses a fixed sensor node and none biosensor). It is an old article, so maybe Berkeleys actual devices like HULC are using a different solution. The whole problem of the system is not bandwith itself, but as i saied before, the lattency. Bus speed is just to reduce that. There is another article with a better explanation of the communication system. As you can see on the end of the article.. you can see that they can transmit 140 bytes on 20us. Thats the whole point. Thats very different of transmiting 1400 bytes on 200us (if you consider a bulk transmission). The solution used at Bleex have 2 problems.. the cypress chip is too old (probably close to be dicontinued), and very very expensive (close to 100 USD e.u). A system that is using a solution closo to what i am developing so far is the Robounaut II. There are a few articles with more detailed technical description but they are on IEExplore... Any way they are using M-LVDS.. but on a more specific way becouse an FPGA placed on central processor is doing a lot of the control processing. Any way, any other suggestions?

Thank you!

--------------------------------------- Posted through

te

ry

f,

nt

y c

If all the nodes are within 10 feet, you can just USB and HUB them. You might want to have multiple USB Host chips to balance the traffic. USB can do 64 bytes in less than 20us.

te

ry

f,

nt

y c

Just wondering, is there a fiber-optic network/LAN protocol that could work?

We probably going to use fiber on further versions, but as none on the team has experience with fiber, we are going to use copper for now. Back to USB. How can i use 1 usb cable to go through all nodes? Use a hub on each node?

And how can i get 20us with an RT Linux? thnks

intermedia=

ve=

the

would

an

itsel=

they

differe=

transmission).

old

100

developing

II.http://www-robotics.cs.umass.edu/~rplatt/paper=>s/robonaut_overview_icr....

the=

specifi=

--------------------------------------- Posted through

I thought they are mounted on humans, not giants.

B.

?

One hub per 4 to 8 sensors. 4 to 5 layers of hubs. 255 sensors max.

Use dedicated USB host chips, fully interrupt driven stack. Offload your control FSM onto the dedicated chips, only store and forward bulk data on Linux.

The reason to use fiber would be noise imunity. But a shilded twisted pair for now is ok for now. But i could not get.. You say to use a hub for node groups.. but they are aligned.. imagin an pearson's arm and nodes distribuited over the arm. So if we use a hub... there are on cable from each nod going to the hub.. thats a lot.. and finally.. you told me it is possible to send 64B with a 20us time with USB. That would be ok if i could address many nodes with one message. But 20us for each node for the request and answer would be something like 120us of lattency for 3 nodes on a channel for data transmission. WHat is the reliability on this number? And are you including the Linux response time? Thank you!

--------------------------------------- Posted through

r e

ld

st

d

No, just raw USB data transfer.

12,000,000 bits per sec =3D 4,000,000 bytes per sec =3D 80 bytes per 20 uSec

But USB frames are limited to 64 bytes, perhaps a little bit less.

What is the minimum USB polling interval these days ?

In the UHCI days, it used to be 1ms, then it dropped to 125us for USB 2.0.

Since people here are talking about 20us been achievable, it's obviously dropped further but a quick search online only found the EHCI era 125us specs.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

pair

node

om

is

could

quest

And

.

You must have fully interrupt driven bulk transfer, not polling, and not running on window. The polling interval defines how often window polls the controller, but you can get better response time by interrupts.

Yes, I've now looked through the EHCI spec itself and found the async capability in the spec although I have not found anything about the minimum latency achievable yet.

Up until now, my detailed (register/data structure level) knowledge was restricted to the UHCI spec although I was aware of some (but not all as it turns out :-)) of the additional features available with EHCI controllers.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

2.0.

ly

s

um

The minimum latency is a reasonable compromise of all universal devices; namely, all devices must meet this requirement. Furthermore, it specify the max. polling overheads on the host side. These are general rules, but more like guidelines anyway. However, if you know your hosts and devices, you can push beyond that. Of course, it would not be universal anymore, but who cares.

In our case, we are using one host to one device pair. So, our host controller has nothing better to do then to poll the device constantly anyway.