Transparent datamode question

[joecool]

This may or may not be related to the 2.2 Beta version since I did not get the chance to test this mode with 2.1.26:

I have two nodes running the Datamode2.py script. Everything is working correctly and the "wireless serial port" functions perfectly. In an attempt to monitor the data that was being sent, I clicked the "Intercept STDOUT" button on one of the nodes. I could see the data in my Event Log, but this caused the wireless serial port link between the two units to stop working (the devices that were talking indicated they were no longer talking). Maybe it is because it introduced timing delays due to the node having to send packets to Portal for its captured STDOUT. Maybe this just isn't allowed in transparent mode? In any case, once I enabled the intercepted STDOUT, I could not disable it. The icon changed states from pressed to unpressed, but it's as if the node never got the notice to stop sending STDOUT to Portal. I say this because I could still see that node's data coming in on the Event Log. The only way I could clear up the problem was to power cycle the node in question.

My nodes were set to 9600 baud (unchanged Datamode.py script). I'll do some more testing with a couple of HyperTerm sessions to see if this in fact is killing the serial data link between the two nodes.

[joecool]

Okay, HyperTerm confirms:


Node A talks to node B & vice versa.
Enabling the "Intercept STDOUT" button in Portal for node A kills node A's transmit link with node B. Its transmission are instead now apparently permanently linked to Portal.
Node B can still transmit to node A just fine.
Unclicking the "Intercept STDOUT" icon has no effect - Node A still transmits only to Portal.
The immediate solution for me is to not use the Intercept STDOUT feature when dealing with transparent mode. :)

Is this a 2.2 bug, or does 2.1.26 exhibit the same behavior?

UPDATE: If I click the setOtherNode(address) function on the intercepted node and re-enter the other node's address, everything returns to normal.

[mgenti]

Yes, the intercept STDOUT button in Portal affects any configured transparent mode connection on that node. For more details see this thread.

I will look into why Portal is not stopping transparent data from the node when the toggle button is depressed.

[joecool]

Yes, the more I thought about it, the more it made sense to me (other than the non-functioning intercept button).

[kbanks]

Enabling the "Intercept STDOUT" button in Portal for node A kills node A's transmit link with node B. Its transmission are instead now apparently permanently linked to Portal.
...
Is this a 2.2 bug, or does 2.1.26 exhibit the same behavior?

It's not a bug (and it's not new behavior, you would see the same thing with 2.0 or 2.1).

All of the SNAPpy Data Sources can only be "aimed" at a single destination, and there is only one of each distinct type.

When you use the "Intercept STDOUT" button, you are literally aiming (connecting) SNAPpy STDOUT to the "Transparent Mode" functional block, and aiming the "Transparent Mode" block at Portal.

When you hit the button again, it should disconnect things, but I don't think it "restores" the previous settings (I don't think Portal knows the previous settings). As already posted, Mark is looking into the disconnect aspect, but you will still need to continue to re-establish your original settings.

While I am on the topic... any individual Data Source can only SEND to one other Data Source, but they can RECEIVE from multiple sources.

For example, I can send data from both UARTs to Portal (multiple uniConnect() calls), but I cannot send the data from UART1 to Portal and somewhere else.

[joecool]

When you hit the button again, it should disconnect things, but I don't think it "restores" the previous settings (I don't think Portal knows the previous settings). As already posted, Mark is looking into the disconnect aspect, but you will still need to continue to re-establish your original settings.


That won't be an issue...this was just a proof of concept test for another product idea, and I was too lazy to plug a serial cable into the DB9 connector that I already had hanging off our existing product's pc board. Everything worked flawlessly once I stopped trying to intercept STDOUT.