On 2011-05-17, linnix <me@linnix.info-for.us> wrote:
> On May 17, 4:32�pm, "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote:
>> 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?
>
> No, just raw USB data transfer.
>
> 12,000,000 bits per sec
>= 4,000,000 bytes per sec
>= 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
Reply by linnix●May 17, 20112011-05-17
On May 17, 4:32=A0pm, "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote:
> The reason to use fiber would be noise imunity. But a shilded twisted pai=
r
> for now is ok for now. But i could not get.. You say to use a hub for nod=
e
> 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 cou=
ld
> address many nodes with one message. But 20us for each node for the reque=
st
> 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? An=
d
> are you including the Linux response time?
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.
Reply by Sink0●May 17, 20112011-05-17
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 http://www.EmbeddedRelated.com
Reply by linnix●May 17, 20112011-05-17
On May 17, 10:45=A0am, "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote:
> We probably going to use fiber on further versions,
I thought they are mounted on humans, not giants.
> but as none on the team
> has experience with fiber, we are going to use copper for now. Back to US=
B.
> How can i use 1 usb cable to go through all nodes? Use a hub on each node=
?
One hub per 4 to 8 sensors. 4 to 5 layers of hubs. 255 sensors max.
> And how can i get 20us with an RT Linux?
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.
Reply by Sink0●May 17, 20112011-05-17
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
>On May 17, 8:11=A0am, "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote:
>> Sorry got very busy on past few days.. back to the discussion.
>> Concentrators are a reasonable idea.. but i am trying to avoid
intermedia=
>te
>> systems due to latency between some signal and systems response. Thats
ve=
>ry
>> 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
>> old article, so maybe Berkeleys actual devices like HULC are using a
>> different solution. The whole problem of the system is not bandwith
itsel=
>f,
>> 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
differe=
>nt
>> 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
>s/robonaut_overview_icr....
>> There are a few articles with more detailed technical description but
the=
>y
>> are on IEExplore... Any way they are using M-LVDS.. but on a more
specifi=
>c
>> way becouse an FPGA placed on central processor is doing a lot of the
>> control processing. Any way, any other suggestions?
>>
>> Thank you! =A0 =A0 =A0 =A0
>>
>> --------------------------------------- =A0 =A0 =A0 =A0
>> Posted throughhttp://www.EmbeddedRelated.com
>
>
>
>Just wondering, is there a fiber-optic network/LAN protocol that could
>work?
>
On May 17, 8:11=A0am, "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote:
> Sorry got very busy on past few days.. back to the discussion.
> Concentrators are a reasonable idea.. but i am trying to avoid intermedia=
te
> systems due to latency between some signal and systems response. Thats ve=
ry
> 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:http://bleex.me.berkeley.edu/Publication/ICRA06Kazsteger.pdfbut
> 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 itsel=
f,
> 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 differe=
nt
> 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.http://www-robotics.cs.umass.edu/~rplatt/paper=
s/robonaut_overview_icr....
> There are a few articles with more detailed technical description but the=
y
> are on IEExplore... Any way they are using M-LVDS.. but on a more specifi=
c
> way becouse an FPGA placed on central processor is doing a lot of the
> control processing. Any way, any other suggestions?
>
> Thank you! =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.EmbeddedRelated.com
Just wondering, is there a fiber-optic network/LAN protocol that could
work?
Reply by linnix●May 17, 20112011-05-17
On May 17, 6:11=A0am, "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote:
> Sorry got very busy on past few days.. back to the discussion.
> Concentrators are a reasonable idea.. but i am trying to avoid intermedia=
te
> systems due to latency between some signal and systems response. Thats ve=
ry
> 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:http://bleex.me.berkeley.edu/Publication/ICRA06Kazsteger.pdfbut
> 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 itsel=
f,
> 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 differe=
nt
> 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.http://www-robotics.cs.umass.edu/~rplatt/paper=
s/robonaut_overview_icr....
> There are a few articles with more detailed technical description but the=
y
> are on IEExplore... Any way they are using M-LVDS.. but on a more specifi=
c
> way becouse an FPGA placed on central processor is doing a lot of the
> control processing. Any way, any other suggestions?
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.
Reply by Sink0●May 17, 20112011-05-17
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: http://bleex.me.berkeley.edu/Publication/ICRA06Kazsteger.pdf 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.
http://www-robotics.cs.umass.edu/~rplatt/papers/robonaut_overview_icra2010.pdf.
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 http://www.EmbeddedRelated.com
Reply by 1 Lucky Texan●May 5, 20112011-05-05
On May 4, 10:15=A0pm, Sink0 <sin...@gmail.com> wrote:
> Well, most of the high sample rate sensors wont be related to
> mechanical sensors, but to biosignals sensors.. and there is a whole
> field of study on how to process that data on real time, and send some
> command before your body can even proccess its own signal. I am
> talking something that can range between 20Hz to 300Hz.. so thats why
> the high sample rate, and i cant just filter it becouse some theories
> makes use of the frequency composition of the signals. Sending the
> data only when its change is ok, and will be implementing with a
> tolken ring logic topology (for now on a M-LVDS Bus), but on i must
> consider a worst case scenario, where everything is changing all the
> same time, and probably that is going the be the most unstable
> movement. The 2kHz control routine is a good number, most of the
> system around the world use some number close to that. Longer control
> loop might lead to some undesirable behaviors with the state of art
> control routines. Of course to find a more robust one, is one of the
> big challenges.
>
> About USB, i cant belive i can get to that lattency in special if i am
> talking with a single cable to lots of nodes. Any good example that i
> could sample 12 different slaves on 100us? Well, i cant see how to
> make use of Ethernet without all the basic overhead.. most o the
> messages will be as big as the 64 Bytes of data.. or close to that..
> And both Ethernet and USB are undesirable due to the phisical
> topology. Star is not good, TOO many cables. Most is acceptable is one
> cable (with many wires inside) for data and log powering, and 2 cables
> for actuators powering.. crossing each joint. EtherCAT is good becouse
> it does not need a Router, HUB or anything other than the EtherCAT
> controller. FireWire can Daisychain..... So a RING, or Bus topology
> would be the prefered ones.
>
> Anyway i am tired now (kinda late here) so i will think again on the
> sugestiosn tomorrow. Thanks!
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?);
http://www.youtube.com/watch?v=3DzrxHMOW67FM&list=3DPL93A1D8E195356D90
Reply by Marc Jet●May 5, 20112011-05-05
On May 4, 2:44=A0pm, Sink0 <sin...@gmail.com> wrote:
> Marc, CAN would be perfect, but it is too slow, and i cant belive the
> arbitration scheme used on CAN could be used on a 50-100Mbps
> communication system. Ethernet, is fast for big packages, but VEEERY
> slow for small and distribuited ones (thats the reason for the
> existency of EtherCAT) due to a big latency between packages.
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