Building a Robot One Motor at a Time

Hi @inq,

Gosh! You're making me feel really old.

 I think you are younger than I am ... so imagine how I feel ... 🤨 

I remember reading about Token Ring, (but never actually saw it in use), which, if my memory serves me correctly, expected each node to 'receive' and 'retransmit' each packet, excepting the node that had originated the packet, which could check the message was unchanged, and had completed the whole ring. This scheme meant that a corrupted message would be detected by its originating node, who could attempt a retry.  However, if one node lost power, then the whole ring would be doomed, because the retries would also fail.

--

The 'coax Ethernet' should have been fine with one or more nodes powered down, as the signal simply travelled (both ways) along the coax cable, until it met the terminator resistor at the end. This principle was fine, but my experience of it meandering around the lab/office areas that I worked in, where it had been previously been fitted by person(s) unknown, who had cut it and joined it at every outlet socket, consistently expecting the wire to stretch an extra few millimetres. Hence, every few days, the connection at one of the (many) joins would fail, and the whole transmission line principle would collapse, resulting in scrabbling behind desks, etc. to access the sockets, and figure out which one had a broken connection. I didn't have any neat gadgets, but a scope looking for the timing of reflections of the default traffic, to estimate a wire length to the break made the job a lot easier.

Note, for anyone reading this who has not 'met' transmission line theory, that a break in the wire does not simply divide a single network into two 'half networks', because when a signal travelling along the wire reaches the open circuit point, it reflects back down the wire, mangling the following bits in the message. That's why a terminator resistor is required at each end of the cable to absorb the electrical energy and prevent it being reflected back.

-----

Of course, the TCP/IP protocols include provision for both retries of lost/corrupted packets, and the alternative of sending packets, accepting any losses without retry, depending upon the nature and use of the message.

I haven't read the I2C specification to check how it deals with these situations, but I might expect a transmitter to retry sending a message that it has aborted due to a bus contention it detected, but any 'higher level', such as resending a message that failed to reach the destination, but looked 'good' to the sender who would be watching the bus, would need to be built into an external software routine.

I think CAN bus takes this philosophy, albeit, by default, a CAN bus transmitter looks for an acknowledge bit being set by a node that is not the sender. This acknowledge only indicates that "a" node has seen the message, with no CRC errors, but does not indicate it has been seen by "a" particular node. If the sender does not see the acknowledge bit being set, it may automatically retry a number (10 perhaps?) of times, before eventually reporting a failure.

-----

The ready availability of compact, cheap microprocessors/controllers has spawned a number of networking alternatives which are scaled in size, complexity, cost etc. to meet the requirements of 'local' communications, leaving Ethernet (and others), which tend to require more hardware, etc. for more demanding applications.

I2C and SPI are not universal solutions, but rather lightweight alternatives for situations that meet their constraints.

Furthermore, although I2C and SPI may both be suitable for some applications, I2C is designed for situations with multiple controllers and/or multiple listeners, albeit at low to moderate bit rates, whilst SPI can support higher bit rates in essentially a one-to-one relationship, with some extension options. Both I2C and SPI were originally aimed at network lengths of below about 1 metre, although with care that can be stretched.

CAN bus is an alternate to I2C, which is more robust for 'intermediate' network sizes, particularly in the range of few metres to 10s of metres.

------------

Apologies for diverting this discussion from the original intent of the thread, although I think it could be relevant to the Robot project described ... I hope it is of interest.

Best wishes, Dave

@davee @inq I thought my memory was bad. Depending on topology, every NIC sees every message.

@inq Regardless of what else happens, I'm using M&M.

Posted by: @davee

↑

Hi @inq,

 

Apologies for diverting this discussion from the original intent of the thread

Please don't apologize. This was well worth the read.

Hi Ron @zander,

RE: Depending on topology, every NIC sees every message.

For networks in which the same pair of wires visits every network interface (which excludes the obsolete Token  Ring if my memory is right), then clearly this should be the aim if you are considering the point at which the interface touches the network cable.

However, even for networks that do directly connect with a single pair of wires, there are a couple of points to catch the unwary, especially those who are less familiar with transmission line theory.

1. Networks of significant length .. i.e. the propagation time from end to end approaches or exceeds the bit time, then the voltages at different interface points may be quite different. For a 'healthy' network, it is normal to put terminating resistor loads at the extreme ends to minimise reflections, and for networks like CAN bus and I2C, the bit rate is limited to ensure the signal at all points along the wire has had time to settle to a common value for each bit, before the interface samples it. Failure to keep to these (and other related requirements) can result in a system that doesn't work because the interfaces are observing different signals, even though simple continuity tests with an Ohmmeter suggests it should be fine.
2. Some networks, e.g. CAN bus, include programmable hardware interfaces that match the incoming address with a list of 'acceptable addresses'. Packets which do not have an 'acceptable address' are ignored and not reported as being received.

With short network lengths, say less than 1 metre end-to-end length, using the slower network systems like I2C, are unlikely to see the transmission line issues, but for higher bit rates and longer networks, these issues can be significant.

As a very rough guide, the propagation speed of a network cable is typically around 65-70% of the speed of light .. say 8" or 20cm per nanosecond. Remember that real driver chips take time to change level, and this too takes some of the bit time, which must be allowed for when estimating a network performance limit.

Each of the commercial network types also has its own 'quirks' which have been included to address certain issues, but typically cause confusion to newcomers of that particular network type. This means very careful 'RTFM' is advised.

Best wishes, Dave

@davee Sorry, not what I was driving at.

@davee @inq It's no secret that the main reason for Token Ring's failure was its lack of scalability. IBM was well aware of this but what was not known outside of IBM was why they produced such a solution. I can tell you it was intentional.

@davee Regarding a serial network bus, I'm thinking I have a lot on my plate as it is. I'd still like to try the RF over DC design, but for the moment I can get things running using Bluetooth, then migrate later.

@fester225 That's a curious approach starting out with wireless (Bluetooth) controls (joysticks?) then switching to a wired connection.

Hi @fester225,

  Of course, there are many ways of building multi-motor systems, and I wish you every success. I am sure a number of forum members will be interested to hear about your project's progression.

Best wishes for the New Year, Dave