Portal 2.2.6 blue mac (local) problem

[korda]

What does that mean if we have a good (USB) connection, have a list of nodes on the screen, but local mac (usually blue) is not listed or not blue color (now black)?
PC is Vista home ed desktop.

[Jheath]

Vlad,

If your bridge node is not indicated in blue, try either...

1) disconnecting and then reconnecting via the options menu or

2) executing the 'new configuration' command from the 'Network' menu in Portal. A word of warning though - This will clear out all existing nodes and will attempt to re-discover the network. If you have a large number of nodes this could take a while. If you have nodes that are currently offline, they will not be rediscovered (until they are online again).

Note: The current Portal network configuration can be saved and restored at a later time by using the 'Save Configuration As' and 'Open Configuration' options from the 'Network' menu in Portal.

[korda]

I do not think this is software issue, since all other nodes shown as blue in Portal, if plugged in. But we have some "strange" RFET nodes, that do something like this. All other functions appears to be ok.
So, what does that mean?

[Jheath]

What version of firwmare are the nodes running? 2.2.6 is a pre-release (Beta) version of Portal.

[mgenti]

The node that Portal highlights with blue just indicates which node was determined to be the bridge node. If Portal does not highlight a node blue than Portal did not get a response when it sent a query to determine the bridge node.

[korda]

It is the one embedded in the portal 2.2.6. I think it is 2.18 firmware

[korda]

By the way, when this happens, Portal has list of all other nodes currently active, among them is the black bridge. It is hard to find it that way and very easy to make mistake.

Also, different issue - why inside of one program you cannot keep track if COM port is open already? I refer to functions like Default, Erase, Upgrade. It is so inconvenient to close port and open again (in the same program!) for different functions...
Also, Portal never remembers which comport to use for these functions.

[mgenti]

While developing SNAPpy scripts here we usually have our bridge node connected via USB so remembering what port we are using wouldn't help much since upgrades can't be done via USB. I guess it's one of those personal preferences things that depends on how you are using Portal.

[korda]

Are you suggesting to connect with both cables then, USB and COM?
Please explain, as I do not understand what you mean.
As we understood USB is not much of the help for special functions. So one has to use COM port. If this correct, then Portal remembering COM# every time you trying to connect saves a LOTs of clicking just selecting COM port number. After we use upgrade, default, we need to upload new script. So the user is forced to make connection again (which he was using just a second ago!). By the way USB is connected to a wrong UART0, so there is no way we can use USB at that time.

[korda]

My fault - we walked away from the main question - if one RFET passes all tests but does not show in blue in Portal - what does that mean? Should we fail this module or use it?
We test modules in question for an ability to connect with UART1 and UART0. We make sure they have latest firmware and able to Default, Erase etc. Also testing transmitter/receiver if functions. This is why I mentioned not friendly COM port i/f in Portal - we spent more time on selecting COM ports instead of testing.

[kbanks]

The idea of allowing "Factory Default", "Erase SNAPpy Script", and "Firmware Upload" on one COM port, while Portal does it's "primary" communications on another COM port (or USB) is already in our "feature bucket". (So many feature ideas, so little time).

Having some of the settings (like the COM port) default to their previous values is also a good idea, and I am going to go enter it into the "feature bucket" right now.

[kbanks]

I think we posted at the same time. My previous post goes with your next-to-latest post...

As for evaluating a node, I would say if it responds properly to several "Refreshes" (the Refresh button on the Node Info toolbar), then the node is talking fine and can be used.

I think the current "blue coloring" in Portal has some limitations such that if Portal does not "notice" the bridge initially, it may not notice it until the next "Network -> New Configuration...".

[admin]

if one RFET passes all tests but does not show in blue in Portal - what does that mean? Should we fail this module or use it?

I wouldn't do a functional test on a module running pre-release BETA firmware. As posted by Kevin, if the node is directly connected and you get responses when choosing "Refresh" on the node than I would consider the serial port to work fine. We are still working on the 2.2 release so seeing some bugs like this where the bridge nodes don't always highlight blue is something we are still looking at.