Do you think MLVDS got some future?

Nobody ever got fired for using MIL-STD-1553.

My guess would be, other than maybe video, many 'robotic' functions don't require the data rate LVDS is capable of. I dunno, maybe system clock sharing/distribution.

1 MBit/s is probaly a lot less of what Sink0 thought of...

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

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.

or

d

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!!

Sink0 wrote: ...

Hey, you mix electrical and logical protocoll...

You can do CAN on MLVDS...

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

That you know of -- there's an absolute ton of electrical, software and even mechanical overhead for it which makes a lot of sense in a big ol' airframe but is absolutely stupid for something smaller in a controlled EMC environment.

It's one of those interfaces that's absolute genius for what it was designed for (including IC technology), but it is by no means a universal 'best' comm system.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Most LVDS specifications are just for the lowest slice of the phy layer, so it makes sense that you'd only be finding transceiver (phy) chips.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

How do you know this? 1553 is a very old military standard designed for use in aircraft. As such it is optimized for different needs than would likely be useful in a robot unless the robot and is very large and has wings. The commercial aircraft use a different interface. It is also very expensive and bulky compared to what the OP is likely looking to use in a robot.

Rick

for

sed

d

What's the question?

Rick

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").

em for

used

ind

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.

stem for

be used

find

s.

a r e

well, these guys developed it;

and it looks like some instrument bus guys may have some interest in it;

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!!