Snapy 2.1 beta - serial

[korda]

Kevin,
We have tried to use Synapse 2500 kit boards to test serial data send between Portal and a Node, based on your recommendations.
We assume the COM1 is wired to the RS232 connector on these boards. A PC is connected to node's serial port to monitor /send data.
We have also implemented new NV parameters 13, 14, 15, with the following:
#13, 50
#15, 5
#14, 123

Unfortunately, nothing worked as planned, no data passed in either direction. The PC monitoring node's serial port displays lots of traffic from surrounding nodes, including error messages, which WilliamM described in his post earlier.

Can you re-test this functionality on 2.1 beta and send us script you using if this works?

PS: We had Bridge node using COM1 for Portal communication. When we load this node with the script using COM1 as STDIO for user messages with Portal, all comms stopped. We had to switch to USB on bridge and comm with portal was restored. But I understood it is pretty much the same for a Node - USB or COM1? Or USB is using COM0?

[kbanks]

Kevin,
We have tried to use Synapse 2500 kit boards to test serial data send between Portal and a Node, based on your recommendations.
We assume the COM1 is wired to the RS232 connector on these boards. A PC is connected to node's serial port to monitor /send data.

To reduce confusion, let's refer to the PC serial ports as COMx (COM1, COM2, etc.), and let's refer to the serial ports on the Synapse boards as UARTx (UART0 and UART1).

Using this naming convention, the USB port is UART0, and the RS-232 port is UART1.

When initializing serial ports via initUart(), UART0 = 0 and UART1 = 1.

When using the crossConnect() and uniConnect() functions, DS_NULL = 0, DS_UART0 = 1, and DS_UART1 = 2.

Which of these serial ports connects to your PC's COM1/COM2/etc. depends on how you ran the cables.

For example, you might connect a serial cable from your PC's COM4 port to the RS-232 connector on the Synapse board. In your terminal program you would specify COM4, and in your script you would specify UART1/DS_UART1.

We have also implemented new NV parameters 13, 14, 15, with the following:
#13, 50
#15, 5
#14, 123


So the maximum DATA MODE packet that could be created would be 123 bytes (#14). However, that will never happen because #13 = 50 says that 50 milliseconds after the first character is received, the data should be forwarded. Also, #15 = 5 says that if 5 or more milliseconds elapse between characters, the data should be forwarded.

Unfortunately, nothing worked as planned, no data passed in either direction. The PC monitoring node's serial port displays lots of traffic from surrounding nodes, including error messages, which WilliamM described in his post earlier.

I assume the PC to monitor/send data is running some sort of terminal program?

Please email me a screenshot or terminal capture of the data you are seeing. From your description, I cannot tell if you have the serial port incorrectly configured for PACKET SERIAL, or incorrectly configured for STDIO. (To be using DATA MODE, the port should be configured for DATA MODE).

Can you re-test this functionality on 2.1 beta and send us script you using if this works?

I ran data mode tests last Monday. I will try and post some new examples later today. In the meantime, please go ahead and email me your current (non-working) script, as it will provide me additional clues as to what exactly you are trying to do.

PS: We had Bridge node using COM1 for Portal communication. When we load this node with the script using COM1 as STDIO for user messages with Portal, all comms stopped. We had to switch to USB on bridge and comm with portal was restored. But I understood it is pretty much the same for a Node - USB or COM1? Or USB is using COM0?

It sounds like you are trying to use the same serial port for more than one function. If you are using the RS-232 port for DATA MODE or STDIO, then yes you will have to put the PACKET SERIAL on the USB port.

[korda]

WilliamM is going to provide our combined script today for testing.

[korda]

Kevin,
Please advise for RFET most efficient serial configuration, to fit our following needs:
- Both UARTs enabled, UART0 for custom data, UART1 for the future firmware updates. Or vise versa.
- At the same time we would like to keep USB functionality on the bridge RFE.
- UART0 passes data between local "smart device" and Gateway/Portal.
- Bridge RFE does not have smart device connected, only PC.
- custom data always sent between RFE and PC, not between RFEs.
- custom data packets no more than 123 bytes.
- LARGE number of RFEs.

The configuration above sounds simple, but I think there is a conflict on the Bridge. So - can be firmware updates made over UART0? Do you really need CTS, RTS lines for firmware updates? Can the firmware updates made over radio?

[kbanks]

WilliamM is going to provide our combined script today for testing.

We got your email, and I took a quick look at script snippet SERIALnode.py.

The script will not compile because it is missing a function called sendMessage. I assume this is just due to you cutting down your script for us to look at, and is not a real issue.

However, in looking at the script source code I did not see any crossConnect() or uniConnect() calls. You are initializing your UART, but you are not establishing DATA MODE.

(I assume you intend to use DATA MODE because your script is setting the NV parameters for DATA MODE.

[kbanks]

Please advise for RFET most efficient serial configuration, to fit our following needs:
- Both UARTs enabled, UART0 for custom data, UART1 for the future firmware updates. Or vise versa.

Only UART1 can accept a firmware upgrade, so you must provide access to that serial port if you want to be able to upgrade the RFE while it is plugged into your board.

However, the "updater" functionality only runs on that port right after the unit boots up. If no updater program (like Portal) tries to send it new code, the port becomes available for SNAPpy script use. So you don't necessarily have to "reserve" UART1, if you are able to unhook your "custom data source" from UART1 when you want to do firmware updates.

- At the same time we would like to keep USB functionality on the bridge RFE.
- UART0 passes data between local "smart device" and Gateway/Portal.
- Bridge RFE does not have smart device connected, only PC.
- custom data always sent between RFE and PC, not between RFEs.
- custom data packets no more than 123 bytes.
- LARGE number of RFEs.

The configuration above sounds simple, but I think there is a conflict on the Bridge.

I don't think you have a conflict, because you say the Bridge RFE does not have a smart device connected. In the script for the bridge, put Packet Serial on UART0 (the USB port). The bridge script will be different than the other node's script.

So - can be firmware updates made over UART0?

No, only UART1.

Do you really need CTS, RTS lines for firmware updates?

The current firmware uploader does not use RTS or CTS.

Can the firmware updates (be) made over radio?

No

[korda]

I am not sure about the data mode selection for crossConnect(). I understand uniConnect() is not what we need.
Data sources are not explained in the manual well, specifically I think our scheme (UART0<-->Gateway) is not shown. According to the cross table in the Reference manual p14, we should use PACKET_SERIAL for RemoteGateway. Is this is the way to setup UART0 on each node?

[kbanks]

Take another look at the post I made yesterday. In particular notice the following:

In the script for the bridge, put Packet Serial on UART0 (the USB port). The bridge script will be different than the other node's script.

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.

The other nodes (the "non-bridge" nodes) need a different configuration. They need their ports configured like the seismic.py example I posted. This script puts their serial ports into DATA MODE (not Packet Serial). This allows them to send serial port data to any other node, including Portal/Gateway.

Here is a portion of that seismic.py example script


def startupEvent():
"""This is hooked into the HOOK_STARTUP event"""

initUart(1, 19200)
flowControl(1, False)

crossConnect(DS_TRANSPARENT, DS_UART1)
uniConnect(DS_UART1, DS_STDIO)
ucastSerial(portalAddr)

crossConnect(DS_PACKET_SERIAL, DS_NULL) # ensure Packet Serial not fighting us for this port


Let's go through it piece by piece.


initUart(1, 19200)
flowControl(1, False)


With the above function calls, you have specified what baud rate you want, and no flow control. However, you have not yet said anything about where incoming characters go, or where outgoing characters come from.


crossConnect(DS_TRANSPARENT, DS_UART1)


With the above function call, NOW we know where serial data comes and goes... DATA MODE AKA TRANSPARENT MODE. We still have not said who the "other end" of the transparent link is. Also note that any unit speaking DATA MODE could send data TO US, which we would forward out the serial port.


ucastSerial(portalAddr)


With the above function call, we now have said who the "other end" of the transparent link is.

Note that this other node may only be reachable across a Packet Serial link (in other words, through a "bridge"), but it does not mean THIS node has to talk Packet Serial.


uniConnect(DS_UART1, DS_STDIO)


With the above function call, you have created an ADDITIONAL way to send data out the serial port. With SNAPpy's STDIO uniConnected to UART1, any print statements made by that node will also go out UART1.

This is in addition to the DATA MODE path, which still exists.


crossConnect(DS_PACKET_SERIAL, DS_NULL) # ensure Packet Serial not fighting us for this port


This is an extra step that has become necessary for some reason. I am trying to reproduce the problem (so I can then track down the error and fix it). In the meantime, everybody should do this extra crossConnect to avoid getting an assertion from the Packet Serial code.

[korda]

We have tried the script you provided and it did not work, sorry.
To make it partially work, we added another line, so serial setup now looks like this:
initUart(1, 9600)
flowControl(1, False)
crossConnect(2, 3) #uart1 & data mode
uniConnect(2, 4) #uart1 & stdio, could you explain this line?
ucastSerial (addrPortal) #could you explain this line?
stdinMode(1, False) # was missing in your setup below
crossConnect(6, 0)
The bridge node did not have any script.
The setup above loaded in the remote node was able to send data to Portal. We can see data on the Portal screen, which is progress.
Without stdinMode() call the setup above not functional, so we wonder how did it work for your test?
STILL PROBLEM: Node does not send anything out to Uart1, even if we call the function (with single print statement inside) direct from portal. So there is still something missing.

We run out of ideas to try, waiting for your instructions.

[kbanks]

uniConnect(2, 4) #uart1 & stdio, could you explain this line?
ucastSerial (addrPortal) #could you explain this line?
stdinMode(1, False) # was missing in your setup below


I explained the uniConnect() and ucastSerial() functions in the post right before yours, I don't know what else to tell you about them.

As for the stdinMode() call, it was missing from my script because it is not needed... in this particular application, STDIN is not being used, so it's "mode" is irrelevant.

For example, notice that the script has no HOOK_STDIN handler.

The only thing I can think of for you to try (and this should not make any difference) is to load your unit with the non-debug firmware image instead of the debug firmware image.

Are you running these scripts on our boards or your boards?

[korda]

We can try non debug firmware today.
We are running tests on your boards out of 2500 kit.
I will test again stdinMode() - if this makes any difference.
In your earlier scripts to us this function was used by some reason.

[korda]

We have tested serial with non-debug firmware and without stdinMode().
Results:
1) works only if we use refresh button on Portal. Discovered by pure luck. WilliamM will report on that.
2) if smart device sends serial data and the very first character is 0x00, Portal does not receive or does not display anything.
3)if we trying to send non-printable chars from portal to "smart device" - error message pops up. We used format "/x00/x...".
Conclusion - serial communication w/Portal cannot handle binary data, only text. We cannot determine where the problem resides portal or node firmware.
4) you were correct - we do not need stdinMode() with non-debug firmware.

[kbanks]

I just ran another round of tests, and I get the same (working) results with debug or non-debug firmware (They both work for me). So I don't think there is an issue with the debug build.

I am also not seeing the "Portal refresh" problem on my PC, but we are seeing it on some other machines here. We will get you an update as soon as we find the underlying cause, and fix it.