Gateway 2.1 closed Beta

[korda]

About new Gateway:
- not clear how to use "gatwayVersion". The client example does not have it either.
- client example has 3 new functions, something to do with SPY. What is it? No documentation found, comments in code do not help.
- item 7. Transparent mode, also known as data mode, packets are now sent to a listening client. - what does that mean and what is the difference from before?

[mgenti]

not clear how to use "gatwayVersion". The client example does not have it either.
Sorry, that was a type, it should be "gatewayVersion" and it returns the version of the SNAP Gateway as a string
client example has 3 new functions, something to do with SPY. What is it? No documentation found, comments in code do not help.
SPY files are a new feature in the SNAP Gateway and Portal. They are SNAPpy scripts that have been "exported" from Portal. They can then be uploaded to nodes via Portal or the SNAP Gateway. The 3 new function are to upload them to a node and support managing the files.
item 7. Transparent mode, also known as data mode, packets are now sent to a listening client. - what does that mean and what is the difference from before?
In the previous version of the SNAP Gateway you could not receive data mode packets. Now data mode packets destined to the SNAP Gateway are passed onto a listening client.

[korda]

1) Sorry, it was my typo mistake in the name gatewayVersion. However it is still not clear how to use this call in the client . Please provide example.

2) Can you provide example of script code for new transparent mode? We have a problem in general to understand SNAPY serial ports modes and in particular how to make them work with gateway/portal.

[mgenti]

1) Sorry, it was my typo mistake in the name gatewayVersion. However it is still not clear how to use this call in the client . Please provide example.

We apparently forgot to add this to the XmlRpcInterface.cs file. You will need to add the following:

[XmlRpcMethod("gatewayVersion")]
string gatewayVersion();

Then call this function as you would with the other builtin functions.
2) Can you provide example of script code for new transparent mode? We have a problem in general to understand SNAPY serial ports modes and in particular how to make them work with gateway/portal.
Setting up the SNAP node for transparent mode is exactly the same as it was in version 2.0. You will need to setup the destination address as the network address your client software is listening on. Then add a function like the following in your client software:

public void dataMode(string data)
{
SetInfoText(data);
}

[korda]

the gatewayVersion works now. Thanks.

SERIAL - I would appreciate a script example of setting up SNAPY port for a "smart device" bidirectional communication with a Portal/gateway using SNAPYs.
a)Is it a transparent mode or stdio mode?
b)We are thinking to deploy ~100 of smart devices for a phase 1. if works , Phase 2 will deploy ~1000 smart devices talking serial directly to Portal/Gateway. The Portal/gateway requests data, and the particular node responds. The data length no more then 128 bytes.
c)I am completely lost which way should be done this now. The code from examples before does not work.
d)Each SNAPY just passes the serial data, no data analysis of any kind.
e)With your experience, which is the most efficient way of making something like this?

[kbanks]

SERIAL - I would appreciate a script example of setting up SNAPY port for a "smart device" bidirectional communication with a Portal/gateway using SNAPYs.

The attached script shows one way of doing it. The script sets things up so that any serial data received by the unit will be sent to the Portal address (look in the script), and provides TWO paths to send serial data out the unit.

1) Any print statements done by the node will send data out the serial port.

2) Any DATA MODE packets sent TO this node will also get sent out it's serial port.

I think the "print" method (via RPC invocations of routines like sendCmd() and sendCmd1()) will be the easiest for now.

Portal and Gateway may provide other methods in the future.

a)Is it a transparent mode or stdio mode?

For maximum flexibility, my attached example does a mix of both. "print" statements made by the script go to STDOUT, which is connected to the serial port (look for the uniconnect() call in the script). Data Mode traffic can also go out the serial port (look for the crossConnect() call in the script).

b)We are thinking to deploy ~100 of smart devices for a phase 1. if works , Phase 2 will deploy ~1000 smart devices talking serial directly to Portal/Gateway. The Portal/gateway requests data, and the particular node responds. The data length no more then 128 bytes.

Whatever serial device you are hooking up to Portal/Gateway will have to support this sort of command/response behavior.

c)I am completely lost which way should be done this now. The code from examples before does not work.

My test programs here still work. I attached yet another example to this post, you should be able to verify that your Portal is receiving the data (it should appear in the event log). After you get that confirmed, you can try to receive the data in your client program (the dataMode(text) function).

d)Each SNAPY just passes the serial data, no data analysis of any kind.

This makes the use of DATA MODE in the "upstream" (from the node up to Portal/Gateway) direction a good fit.

e)With your experience, which is the most efficient way of making something like this?

Letting the data from the node to Portal/Gateway travel via DATA MODE (AKA TRANSPARENT MODE) has worked well for us on other projects.

Using RPC functions (that then do print statements) has worked well in the "downstream" direction. The RPC commands can be shorter than the actual data to be sent.

[kbanks]

Up to now we have been using RPC calls and print statements to send data "downstream".

We have decided to go ahead and add an additional API function sendDataModePkt(addr, text) to the Gateway (Portal 2.1 already has this, try root.sendDataModePkt(addr, text) from the Portal command line or from a Portal script.)

This will make bidirectional DATA MODE applications simpler to understand.

Data from the nodes will come in to the dataMode(text) function.

To send data back to the nodes, you will use the new sendDataModePkt() function.

This new function will be in Friday's updated Gateway BETA.

[WilliamM]

This is the setup we are currently trying (based off your seismic.py):

initUart(1, 9600)
flowControl(1, False)
crossConnect(2, 3) # UART1 & TRANSPARENT
uniConnect(2, 4) # UART1 & STDIO
crossConnect(6, 0) # PACKET_SERIAL & NULLUnfortunately, after uploading it to the bridge node, my communication with it died and I can't reconnect to it. I suspect that it is handling an immense amount of traffic. We had problems like this before when we crossConnect(UART1, STDIO) - the nodes become very difficult to reach. Cross connecting PACKET_SERIAL and NULL doesn't seem to have helped.

[admin]

Unfortunately, after uploading it to the bridge node, my communication with it died and I can't reconnect to it.

The script you loaded to the bridge node did exactly as you programmed it to do. In the script we programmed packet serial to go no where. Packet serial is the protocol we use to talk to Portal or the SNAP Gateway. From what you have described the bridge node is not doing anything other than talking to the nodes and the SNAP Gateway. If this is the case you don't need to upload script into that node.


One node (the "bridge" node) will have to use one of its serial ports to talk Packet Serial to Portal or a Gateway. This one node will allow Portal/Gateway to reach all of the other nodes. All of the other nodes will be able to reach Portal/Gateway through this "bridge" node.

Only the "bridge" node has to have a UART configured for Packet Serial.

[korda]

I think you last serial setup instructions got us even more confused.
Could you please test these instructions before sending them out or posting on the forum?
We are still waiting on good solid set of instructions on how to connect serial device(s) to a central portal/gateway....

[mgenti]

Could you please test these instructions before sending them out or posting on the forum?
The seismic.py script was tested before posting on the forum and I just retested it before writing this post.

We are still waiting on good solid set of instructions on how to connect serial device(s) to a central portal/gateway....

My seismic.py script testing procedure:
To test this I did NOT load a script into the node I am using as my bridge node to portal. I then edited the scripit and changed the portalAddr to what I have my Portal network address set to, which is shown in the Node Views. I then uploaded the script to a node that is NOT my bridge. I launched hyperterminal and connected to the COM port that is attached to the node I just uploaded the script too. I clicked on the node in node views to display it's node info and then clicked on "sendCmd1()" in the node info panel. I verified that hyperterminal displays the text "command" as expected. I then typed a character in hypterminal and verified that it is printed out in my Portal event log panel.

Please use these steps to verify that you also see the same results.