Do you think MLVDS got some future?

On Oct 6, 11:07=A0am, Sink0 <sin...@gmail.com> wrote:
> On Oct 6, 4:51=A0pm, larwe <zwsdot...@gmail.com> wrote:
>
>
>
> > On Oct 6, 8:29=A0am, Uwe Bonnes <b...@elektron.ikp.physik.tu-
>
> > darmstadt.de> wrote:
> > > larwe <zwsdot...@gmail.com> wrote:
> > > > On Oct 6, 6:13=A0am, Sink0 <sin...@gmail.com> wrote:
> > > > > I was making a research a few months ago to make a control system=
 for
> > > > > a robot and after a while I found MLVDS. It seems perfect to be u=
sed
> > > > > as a network for communication inside a robot but I could not fin=
d
> > > > Nobody ever got fired for using MIL-STD-1553.
>
> > > 1 MBit/s is probaly a lot less of what Sink0 =A0thought of...
>
> > You know this? As usual no information about the application details.
> > So it might be the best protocol ever devised, exactly matching his
> > requirements, or it might be that he only needs to carry data from a
> > couple of I2C temperature sensors sampled at 1Hz, and MLVDS is
> > horrific overkill.
>
> I did not give any information about my application because the answer
> is not about the application, but about MLVDS itself...
>
> But for curiosity, i was thinking on something much faster than 1Mbps
> (but you had no way to know that as you described). But at that range
> i would probably use CAN. Any way, it would be an exoskeleton and not
> exactly a robot hehe. But anyway, the usual (the full one would be the
> double) system would use something like 8 EMG channels sampling at
> 2Ksps with 12 bits resolution (what is low for EMG). Probably 6 or 7
> Brushless motors, 6 encoders (not the one used for the motor control)
> for position control, 5 to 8 3 axis accelerometer and gyro with 10-12
> bits resolution. The system would have 1ms cycle time (the control
> routine). But the system itself is not fixed and any kind of actuator
> and sensor is possible to be used on it.
>
> But back to MLVDS.. any other comment?
>
> Thank you!!

What's the question?

Rick

On Oct 7, 11:51=A0pm, rickman <gnu...@gmail.com> wrote:

> > Nobody ever got fired for using MIL-STD-1553.
>
> How do you know this? =A01553 is a very old military standard designed
> for use in aircraft. =A0As such it is optimized for different needs than

I know what 1553 is (I don't think anybody who knows the name would
not also know the purpose). My comment was to a certain degree tongue
in cheek; without knowing what the OP actually wants to do, who the
hell knows if [insert protocol] is a rational choice? 1553 is the
perfect choice if your vehicle contains existing 1553 electronics, for
instance (and not all 1553 users have wings - even counting spacecraft
as "aircraft").

On Oct 8, 12:53=A0am, rickman <gnu...@gmail.com> wrote:
> On Oct 6, 11:07=A0am, Sink0 <sin...@gmail.com> wrote:
>
>
>
>
>
> > On Oct 6, 4:51=A0pm, larwe <zwsdot...@gmail.com> wrote:
>
> > > On Oct 6, 8:29=A0am, Uwe Bonnes <b...@elektron.ikp.physik.tu-
>
> > > darmstadt.de> wrote:
> > > > larwe <zwsdot...@gmail.com> wrote:
> > > > > On Oct 6, 6:13=A0am, Sink0 <sin...@gmail.com> wrote:
> > > > > > I was making a research a few months ago to make a control syst=
em for
> > > > > > a robot and after a while I found MLVDS. It seems perfect to be=
 used
> > > > > > as a network for communication inside a robot but I could not f=
ind
> > > > > Nobody ever got fired for using MIL-STD-1553.
>
> > > > 1 MBit/s is probaly a lot less of what Sink0 =A0thought of...
>
> > > You know this? As usual no information about the application details.
> > > So it might be the best protocol ever devised, exactly matching his
> > > requirements, or it might be that he only needs to carry data from a
> > > couple of I2C temperature sensors sampled at 1Hz, and MLVDS is
> > > horrific overkill.
>
> > I did not give any information about my application because the answer
> > is not about the application, but about MLVDS itself...
>
> > But for curiosity, i was thinking on something much faster than 1Mbps
> > (but you had no way to know that as you described). But at that range
> > i would probably use CAN. Any way, it would be an exoskeleton and not
> > exactly a robot hehe. But anyway, the usual (the full one would be the
> > double) system would use something like 8 EMG channels sampling at
> > 2Ksps with 12 bits resolution (what is low for EMG). Probably 6 or 7
> > Brushless motors, 6 encoders (not the one used for the motor control)
> > for position control, 5 to 8 3 axis accelerometer and gyro with 10-12
> > bits resolution. The system would have 1ms cycle time (the control
> > routine). But the system itself is not fixed and any kind of actuator
> > and sensor is possible to be used on it.
>
> > But back to MLVDS.. any other comment?
>
> > Thank you!!
>
> What's the question?
>
> Rick- Hide quoted text -
>
> - Show quoted text -

I dont know why my answer was not posted here ... i probably did make
a mess. Any way. first of all, i know that MLVDS is a phy layer and
thats it. But as i wrote before, i did not find any kind of
information of its use on ay field with any data link layer, with any
Protocol on it. Nothing. All i found was 2 palpers related of the use
of it on Robots (as a replacement for RS485). But both articles make
use of a FPGA with a custom driver for the communication. The directio
of my questin was if any one had any kind of experience with this phy,
and if its use is already well defined. The answer that i am looking
for would be something like industrial automation with a fieldbus
protocol for RS485, but for MLVDS. I know it looks stupid, And about
the CAN, well thats not totally true. A CAN is a Data Link Protocol
but with some phy restriction. At a CAN bus, a logic level low must be
dominant over logic level high (for data collision arbitration), and i
am not sure if MLVDS would behavior like this. And fianally, as both
applications that i found, a FPGA was used as a Driver. It is very
weird to find a technology that you must develop your own driver to
make a good use of it.

Thank you!! Sorry for being confuse.

On Oct 9, 5:31=A0am, Sink0 <sin...@gmail.com> wrote:
> On Oct 8, 12:53=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Oct 6, 11:07=A0am, Sink0 <sin...@gmail.com> wrote:
>
> > > On Oct 6, 4:51=A0pm, larwe <zwsdot...@gmail.com> wrote:
>
> > > > On Oct 6, 8:29=A0am, Uwe Bonnes <b...@elektron.ikp.physik.tu-
>
> > > > darmstadt.de> wrote:
> > > > > larwe <zwsdot...@gmail.com> wrote:
> > > > > > On Oct 6, 6:13=A0am, Sink0 <sin...@gmail.com> wrote:
> > > > > > > I was making a research a few months ago to make a control sy=
stem for
> > > > > > > a robot and after a while I found MLVDS. It seems perfect to =
be used
> > > > > > > as a network for communication inside a robot but I could not=
 find
> > > > > > Nobody ever got fired for using MIL-STD-1553.
>
> > > > > 1 MBit/s is probaly a lot less of what Sink0 =A0thought of...
>
> > > > You know this? As usual no information about the application detail=
s.
> > > > So it might be the best protocol ever devised, exactly matching his
> > > > requirements, or it might be that he only needs to carry data from =
a
> > > > couple of I2C temperature sensors sampled at 1Hz, and MLVDS is
> > > > horrific overkill.
>
> > > I did not give any information about my application because the answe=
r
> > > is not about the application, but about MLVDS itself...
>
> > > But for curiosity, i was thinking on something much faster than 1Mbps
> > > (but you had no way to know that as you described). But at that range
> > > i would probably use CAN. Any way, it would be an exoskeleton and not
> > > exactly a robot hehe. But anyway, the usual (the full one would be th=
e
> > > double) system would use something like 8 EMG channels sampling at
> > > 2Ksps with 12 bits resolution (what is low for EMG). Probably 6 or 7
> > > Brushless motors, 6 encoders (not the one used for the motor control)
> > > for position control, 5 to 8 3 axis accelerometer and gyro with 10-12
> > > bits resolution. The system would have 1ms cycle time (the control
> > > routine). But the system itself is not fixed and any kind of actuator
> > > and sensor is possible to be used on it.
>
> > > But back to MLVDS.. any other comment?
>
> > > Thank you!!
>
> > What's the question?
>
> > Rick- Hide quoted text -
>
> > - Show quoted text -
>
> I dont know why my answer was not posted here ... i probably did make
> a mess. Any way. first of all, i know that MLVDS is a phy layer and
> thats it. But as i wrote before, i did not find any kind of
> information of its use on ay field with any data link layer, with any
> Protocol on it. Nothing. All i found was 2 palpers related of the use
> of it on Robots (as a replacement for RS485). But both articles make
> use of a FPGA with a custom driver for the communication. The directio
> of my questin was if any one had any kind of experience with this phy,
> and if its use is already well defined. The answer that i am looking
> for would be something like industrial automation with a fieldbus
> protocol for RS485, but for MLVDS. I know it looks stupid, And about
> the CAN, well thats not totally true. A CAN is a Data Link Protocol
> but with some phy restriction. At a CAN bus, a logic level low must be
> dominant over logic level high (for data collision arbitration), and i
> am not sure if MLVDS would behavior like this. And fianally, as both
> applications that i found, a FPGA was used as a Driver. It is very
> weird to find a technology that you must develop your own driver to
> make a good use of it.
>
> Thank you!! Sorry for being confuse.



well, these guys developed it;
http://www.ddwg.org/

and it looks like some instrument bus guys may have some interest in
it;
http://www.lxistandard.org/Default.aspx

On Sat, 9 Oct 2010 03:31:18 -0700 (PDT), Sink0 <sink00@gmail.com>
wrote:

>I know it looks stupid, And about
>the CAN, well thats not totally true. A CAN is a Data Link Protocol
>but with some phy restriction. At a CAN bus, a logic level low must be
>dominant over logic level high (for data collision arbitration), and i
>am not sure if MLVDS would behavior like this. 

Before the first actual CAN driver were available, the CAN bus was
implemented using RS-485 hardware. The recessive state (mark) was
implemented with fail safe termination and driver in tri-state. The
dominant (space) state was implemented by enabling the driver with a
fixed space state at driver input. Thus, the digital data was
connected to the driver enable input and the signal input tied to
space state.

The MLVDS should work in this configuration as well, provided the
driver ebable/disable times are similar to the data I/O pin rates.

Of course CAN style dominant and recessive states can be implemented
also e.g. wided-OR, 20 mA current loop or using light.

However, the CAN style arbitration has a serious problem, in order to
detect a collision, the two way propagation must be well below a
single bit time. At say 100 Mbit/s, the bit time is 10 ns, the free
space wavelength is 3 m and considering the typical velocity factor
and the two way propagation, this would allow a bus length of 1 m.
However, since the collision detection must occur well within the bit
period for proper action, the practical bus length would be 30-50 cm
at 100 Mbit/s.
 

On Oct 10, 7:27=A0pm, Paul Keinanen <keina...@sci.fi> wrote:
> On Sat, 9 Oct 2010 03:31:18 -0700 (PDT), Sink0 <sin...@gmail.com>
> wrote:
>
> >I know it looks stupid, And about
> >the CAN, well thats not totally true. A CAN is a Data Link Protocol
> >but with some phy restriction. At a CAN bus, a logic level low must be
> >dominant over logic level high (for data collision arbitration), and i
> >am not sure if MLVDS would behavior like this.
>
> Before the first actual CAN driver were available, the CAN bus was
> implemented using RS-485 hardware. The recessive state (mark) was
> implemented with fail safe termination and driver in tri-state. The
> dominant (space) state was implemented by enabling the driver with a
> fixed space state at driver input. Thus, the digital data was
> connected to the driver enable input and the signal input tied to
> space state.
>
> The MLVDS should work in this configuration as well, provided the
> driver ebable/disable times are similar to the data I/O pin rates.
>
> Of course CAN style dominant and recessive states can be implemented
> also e.g. wided-OR, 20 mA current loop or using light.
>
> However, the CAN style arbitration has a serious problem, in order to
> detect a collision, the two way propagation must be well below a
> single bit time. At say 100 Mbit/s, the bit time is 10 ns, the free
> space wavelength is 3 m and considering the typical velocity factor
> and the two way propagation, this would allow a bus length of 1 m.
> However, since the collision detection must occur well within the bit
> period for proper action, the practical bus length would be 30-50 cm
> at 100 Mbit/s.


That was very informative, but yea, as you wrote i am not planning to
use arbitration on this bus, Probably at that speed is not reliable to
use a multdrop network with no master. Thats an opinion, i might be
wrong. There is always the option to use something like Ethercat, but
there is a lack of information about this technology and the options
available would be buy benckoff ASICS or get a FPGA IP. But i cant
find benckoff asics at standards electronic shops (mouser, digikey,
farnell...) and they do not answer my e-mais hehe. Another option i
found would be to use cypress hotlink (as used on Berkeley
Exskeleton). They have a hotlink IC that canb works exactly as
ethercat. But the IC cost 100 USD a piece. Thats too expensive ...  I
am trying to avoid point-to-point communication becouse usually the
reliability of this kind of system is directly related to the number
of cables present on that system (i got this information of my own
experience and from another reference i cant remember right now).
Point-to-point with fiber optic is always an option but that would
bring more complexity and i have no experince with this technology.

The real problem with the Master-Slave options is that your bus must
have a real righ speed becouse you must poll it all the time, as the
nodes cant talk with no master request to avoit data collision.


I could not find any reference on ddwg site about mlvds, just DVI. But
i could find that LXI uses it for sync purposes and not data
tranmission. Thats a good inforamtion, thank you!!

Any one got any sugestion about my problem or further comment?

Thank you!!