Multidrop Serial Scripts

[David Ewing]

Attached are scripts implementing a basic “transparent data” mode connection for a multi-drop serial application. This is a common configuration for wire-replacement in RS422/485 systems.

1. Put these scripts in your “My Documents/Portal/snappyImages” directory.
2. From the Portal application, select the device you want to use as the MASTER, and upload the “transparentMaster.py” script to it.
3. From the Portal application, individually select the devices you want to use as the SLAVEs, and upload the “transparentSlave.py” script to them.

The SLAVE devices will automatically learn the address of the MASTER device and use unicast messages to reliably report back in.

[barry0727]

Suppose you wanted to set up a multi-drop serial transparent mode where the data typically comes from the slaves to the master. For example, we have a situation where we have multiple sensors that need to send binary data to a collection unit, which acts as a gateway to the WAN. If the slaves send data simultaneously to the master, how is the data to the master intermingled? Suppose slave A sends a 200 byte block of data slightly before the same time that slave B does the same. Will the entire packet of data from A come out before the data from B? Is there a way to determine (besides putting a token in the data stream) where the data came from?

I assume that the transparent mode serial data is being broken down into packets, transmitted, and echoed to the serial port on the receiver. A slave application could apply a header to its data to identify itself, but it doesn't know where its data stream will be broken into packets. Is the DS_PACKET mode more appropriate? The information in the SNAP reference manual does not have a lot of the details.

[kbanks]

I would recommend an approach based on explicit Remote Procedure Calls (RPCs).

When your sensor nodes have data to report, they could invoke some function on the master. For example, temperatureIs(latestReading).

The temperatureIs() function would then always be dealing with complete data from a single sensor node.

But let's assume you have to use DATA MODE...

Yes, DATA MODE data is broken into packets. In the past when we have had situations like yours, the remote nodes reported serial data using DATA MODE (AKA TRANSPARENT MODE), but it went to a PC (via the Gateway), and since the Gateway knew which node each "chunk" came from (each packet has a source address), it (the receiving application) was able to keep them separate.

1) Is your remote data really serial?
2) Is your remote serial data stream simple enough that the remote nodes could decode it locally? (characters coming in through a serial port could be routed to a SNAPpy script running in the unit, instead of going through the unit via DATA MODE).
3) Even if your remote nodes must use data mode, does it have to go back to serial data coming out of a SNAP node at the host end?

If the "host side" data is going to go into a PC anyway, then maybe your remote nodes are sending the data to the wrong address. Maybe they should be sending it to Portal or another Gateway client.

[barry0727]

I'm not sure how well the RPC architecture suits our potential application. We have a few situations where our devices transmit very large arrays of binary data. It would also be useful if the radio device does not need to understand the contents of the data message. The host at the end would be an embedded CPU (probably a simple ARM7 or Cortex-M3) with a WAN connection of some sort. If RPC could accommodate packets of binary data of variable length (up to 250 bytes or so), we could use that.

[kbanks]

I'm not sure how well the RPC architecture suits our potential application. We have a few situations where our devices transmit very large arrays of binary data. It would also be useful if the radio device does not need to understand the contents of the data message.

A script could receive serial data via STDIN, and then make an rpc() call to send the data elsewhere, even if it did not look at the actual data.

Again, I suggest the RPC approach just as a way of distinguishing on the host end where the data came from...

The host at the end would be an embedded CPU (probably a simple ARM7 or Cortex-M3) with a WAN connection of some sort. If RPC could accommodate packets of binary data of variable length (up to 250 bytes or so), we could use that.

The maximum packet payload possible is 123 bytes, and packet headers eat 12-15 bytes of that. Your data could come in via multiple packets, though.

[Mark paul]

we used the tranparent mode in the past,but our data was separate and recombine unsequence, so we use time-out mechanism,by about 11 hop,it work well.
we add datalen check,sequencenum(in case the same packet recvce twice or more,this happen when a lot of node and brocast packet),and pick the second data as a check data,to avoid packet receive error(it did happen).

because the mcast() brocas mode have some problem:when the master is brocasting ,several slaver sent data to master ,a lot of data unsequencenum happen,such as the slaver A send "123456789",slaver B send "ABCDEFG",the maser will receive "123456ABCDEFG789", or "78912345678".

manal said the mcast did't have an ack mechanism,so this proven to be unreliable.

[marshall.brown]

Hi there

I am new to the forum so please excuse me if this has been answered elsewhere.

Our application is an autonomous rail system. We have a CAN bus running along side the track that has all switching points etc on it.

The railcars will use the Synapse modules to communicate with any one of the Switching Points as it approaches the points.

CAN has bitwise arbititration and therefore has multimaster capability. Our CAN nodes have a serial port on them and I wanted to fit the Synapse module to these, and provide a point (any rail car) to multipoint (any CAN Node or other rail car) system.

As the points on the track may or may not be in close proximity to each other I was going to convert the serial data from the rail car to CAN, send it down the Bus and have it re broadcast via the synapse modules at all other CAN Nodes.

Of course if 2 nodes are close enough together (or have a mesh dynamically created to them) then the data from one rail car message will go into the CAN node, sent down the wire, retransmitted out another CAN node, and then looped around and around.

How would I overcome this? I was hoping for something similar to Ethernet's STP (Spanning Tree) and hence the reason for choosing an 802. protocol. The meshing is great and must implement loop detection and prevention somehow, how is it done and can it be brought out the serial port.

I see that there is some function that can bring the SNAP protocol out the serial port if you want to change bands, what about if you want to stop the loops, is there some way that I can use this? Is it documented anywhere? where can I get the documentation?

Any thoughts or solutions greatly appreciated.

Regards

Marshall Brown

[kbanks]

Your questions are outside the scope of this forum, you will likely need to contact our Custom Solution Group to have a Synapse Design Engineer work with you.

That said, I will try and touch on some of your topics...

The Synapse SNAP protocol is proprietary. As such, there is no documentation or source code available.

SNAP has now been ported to 5 distinct hardware platforms. If one of these matches your hardware, you're set. If not, we can port SNAP to your hardware for a fee. (This is in regard to extending Mesh Routing beyond the serial port). SNAP already has the ability to talk "plain" serial out the serial port.

As for the specifics of the Mesh Routing, that is also proprietary, but we have already mentioned on this forum that SNAP is close in "spirit" to DYMO. You might take a look at that RFC, particularly in regards to "loop elimination".

As for loop elimination regarding broadcasts, know that SNAP multicast messages include a "Time To Live" (TTL). In other words, each multicast message is sent with a maximum hop count. So, they cannot "loop" forever, they will always "fade out".

Another key point is that with SNAP nodes, serial data does not have to be sent transparently (although that is an option). "Scripted IO" has been discussed many times on this forum (try using the search function on the top menu bar). When sending data using RPC calls, you can include additional information like a "CAN bus address" that might help your application decide if a message should be forwarded (or not).

[vks_01]

I've been trying to use some of the scripts posted here to configure nodes as wireless UARTs. The codes seem to work quite well for small packets of data (<60 bytes), but when I try to send a string longer than 60 bytes, I run into a 'Line too long' error. Is there a way to configure transparent mode and transfer hundreds of bytes data at a time? I am looking at a few tens of bytes in multicast mode (a broadcast from a master), but a unicast from one node to the master which could be hundreds of bytes long. SNAP does not need to know what data is passing through in either direction, it just needs to forward what it gets (regardless of packet size) to the UART and the other way around.

Karthik