SnapConnect vs Portal

[bcuming]

I am having problems running a base unit RF100 (2.4.9) connected to serial-ethernet adapter and remotely to Portal machine. The remote portal has a ethernet to serial conversion to allow the Portal to connect.

The remote Portal PC unit talks thru ethernet and the base RF100 unit and wireless to a remote RF100, but I can not run an rpc call in this configuration. If I plug in a snapstick and try running the same rpc wireless connection to the remote it's OK. I sniffed the air and here are the streams:

Thru serial-ethernet adapter:
0000 1A 04 03 E8 D5 03 E8 E6 00 03 E8 D5 00 00 02 00 ................
0010 02 00 03 07 6E 6D 73 64 61 74 61 ....nmsdata

Thru snapstick:
0000 1A 04 03 E8 D5 03 F8 F4 AB 03 E8 D5 00 00 01 00 ................
0010 02 00 03 07 6E 6D 73 64 61 74 61 ....nmsdata

As you can see the only difference (except the source address) is the "AB" thru the snapstick ("00" thru the adapter). Can you provide suggestions what is wrong?? The "00" from the adapter is stopping the rpc call in the remote RF100 from working.

Thanks

[Jheath]

Can you put together a quick block diagram with Product part-numbers? Also, when you connect to the Portal bridge are you selecting a 'remote connection" or Portal able to detect and associate your bridge with serial port?

[bcuming]

See encl. We are not using remote connection in portal but connecting with a virtual com port generated by VSPE

[Jheath]

In that case Portal has no idea that it is attempting to bridge to something other than a directly connected serial port. It will not alter what it sends.

Does Portal automatically detect the bridge device on this VCP port ( COMxx)?

Can you use the same PC that hosts the VPSE program to connect to an on-board COMM port? (interested in a true COMM port connection rather than USB).

[bcuming]

I had understood the serial connection I set up from the portal -> VSPE -> Netburner -> RF100 to be a transparent serial connection (no different than piping the data through a USB connection. How does the Portal alter the data stream and why?

In the portal I need to select the port that is being allocated by VSPE and click connect. I noticed that many rpc/mcastrpc calls (even the Synapse ones) have the same problem - they go through and are transmitted by the base but ignored by the remote unit. I can perform some functions such as upgrade and basic read/write.

I didn't try connecting to a real PC comm port as I need to communicate through ethernet, but will do so and let you know.

[bcuming]

Problem Update..
Setup 2 in this diagram represents the final architecture for the project. Right now the system acts the same using either the Portal or the application program on the PC - ie the rpc calls are intermittent and unreliable. They are reliably being sent to to the base RF100 and are being transmitted over the air (tested using Sniffer)but the remote unit often ignores the rpc call.

[gvoce]

"the remote unit ignores the RPC", sounds like the remote node does not have a function in the remote node to handle the RPC ???

Are you saying the flow works in one direction but not the other ?

[Jheath]

What type of RPC are you sending? If it is a multicast, are you sure the TTL is set high enough to account for the added hop of the serial connection? If you are using unicast are you 1) sure the address matches the remote node and 2) they are on the same channel/netID?

Also, check the you are not set to ignore certain mutlicast groups. Each node has independent 'mcast forwarding' and 'mast processing' group configurations. By default, all nodes are in group 1 for both settings. Make sure the RPC you are sending matches the group settings of the remote devices.

mcastRpc(mcastGrp, TTL, "rpcToSend", anyParms...)

[bcuming]

Both calls (from snapstick and thru the base unit) are RPC calls, not mcast - to \x03\xE8\xD5, you can see that from the hex info sniffer picked up.

By comparing the over air stream thru the Snapstick vs serial-ethernet adapter can you tell the problem? I do not know how to decode the hex.

gvoce, the rpc call works from the snapstick (I can rpc from the computer with the snapstick) so everything must be ok with the remote unit code.

[Jheath]

Can you post the SNAP-RF sniffer exchange that shows the RPC leaving the bridge device (but not being processed by the end node)?

[bcuming]

They are shown above, here they are again:

SnapSniffer hex when RPC originates from Portal and thu serial-ethernet adapter and goes through base unit: This does not work:
0000 1A 04 03 E8 D5 03 E8 E6 00 03 E8 D5 00 00 02 00 ................
0010 02 00 03 07 6E 6D 73 64 61 74 61 ....nmsdata

SnapSniffer hex when RPC originates from snapstick thru PC: This works:
0000 1A 04 03 E8 D5 03 F8 F4 AB 03 E8 D5 00 00 01 00 ................
0010 02 00 03 07 6E 6D 73 64 61 74 61 ....nmsdata

nmsdata is the name of the subroutine that the remote unit should process when it receives the rpc call above

[Jheath]

Can you send the .sss file (you can save your whole sniffer session) rather than just the hex of the two packets? This tells us a little more about what else is going on surrounding the RPC exchange.

[bcuming]

See encl. but your website would not accept .sss so i changed the extension to txt.

I did some more tests. Simply using the script below running in the RF100 nmsdata sub will run once after power up then will not respond after that. Example line 35 triggered it to run, but next request (line 37) was acknowledged but didn't run the sub. As they look the same I wonder if there is a firmware bug in the RF100??

@setHook(HOOK_STARTUP)
def on_startup():
setPinDir(10, True)


def nmsdata(): # sub called by remote portal
pulsePin(10, 200, True)

Some info: D5 is remote MAC, E6 is base MAC, 0001 is Portal connected through ethernet to base.

[Jheath]

Just to clarify... Everything works as expected when you remove your Serial-to-Ethernet converter?

[Jheath]

The sniffer indicates that the remote received the RPC correctly. There are no known issues with the RF100 (in fact this type of exchange is done thousands of times a day by RF100 users.

I was success in using your test script to pulse an LED at a number of different rates.

What do you have connected to I/O 10 in order to determine if you successfully 'pulsed' the pin?

You could switch you pin to one of our prototyping boards (SN171) or other demo HW and use the onboard LEDs. Also, you can keep count of just how many RPCs you have received.

myPin = 1
totalCount = 0

@setHook(HOOK_STARTUP)
def on_startup():
    setPinDir(myPin, True)

def nmsdata(): # sub called by remote portal
    global totalCount
    pulsePin(myPin, 200, True)
    totalCount += 1
    print totalCount
    
def currCount():
    print totalCount
    return totalCount

def resetCount():
    global totalCount
    totalCount = 0