On May 5, 4:04=A0am, upsided...@downunder.com wrote:> On Wed, 4 May 2011 04:36:51 -0700 (PDT), Sink0 <sin...@gmail.com> > wrote: > > > The whole system should work with a 500us > >period. The max acceptable latency between the PC/104 ask for the data > >and the reception should be 100us, and the maximum latency for the > >actuators command should be 70us (bewtween teh pc104 send and the node > >receive). From all the commercial standard availables, all i could > >find was Ethercat and Firewire, that have a chance to handle this > >communication..Any idea? Just a final comment. The system should have > >the minimum amount of cables possible and the max distance between the > >PC104 and the nodes is 3m. > > 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.Should be fine in either case. Even real time PID controller can adjust with a few delayed samples.> > 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.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.> > 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.Full speed USB is cheap and good enough for this.
Which embedded system would you use?
Started by ●May 4, 2011
Reply by ●May 5, 20112011-05-05
Reply by ●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
Reply by ●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 ●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 ●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 ●May 17, 20112011-05-17
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.comJust wondering, is there a fiber-optic network/LAN protocol that could work?
Reply by ●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 avoidintermedia=>te >> systems due to latency between some signal and systems response. Thatsve=>ry >> critical. Something different from star or Bus is not acceptable duethe>> cable numbers.. and thats another critical part. Just a better >> representation of the complexity of the system. Somthing comaprablewould>> 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 isan>> old article, so maybe Berkeleys actual devices like HULC are using a >> different solution. The whole problem of the system is not bandwithitsel=>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 thatthey>> can transmit 140 bytes on 20us. Thats the whole point. Thats verydiffere=>nt >> of transmiting 1400 bytes on 200us (if you consider a bulktransmission).>> The solution used at Bleex have 2 problems.. the cypress chip is tooold>> (probably close to be dicontinued), and very very expensive (close to100>> USD e.u). A system that is using a solution closo to what i amdeveloping>> so far is the RobounautII.http://www-robotics.cs.umass.edu/~rplatt/paper=>s/robonaut_overview_icr.... >> There are a few articles with more detailed technical description butthe=>y >> are on IEExplore... Any way they are using M-LVDS.. but on a morespecifi=>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? >--------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●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 ●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 ●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.
