Initial reactions

[JohnOH]

When selecting Scan mode this error message always comes out:

can't set "var(state)": list element in quotes followed by ":" instead of space
list element in quotes followed by ":" instead of space
    while executing
"llength $var(statemsg)"
    (procedure "::mon::onStateChange" line 17)
    invoked from within
"::mon::onStateChange var state write"
    (write trace on "var(state)")
    invoked from within
"set var(state) $state"
    (procedure "setState" line 9)
    invoked from within
"setState 0 $err"
    (procedure "::mon::receive" line 8)
    invoked from within
"::mon::receive file3257d30"

System appears to work after clicking OK.

[dzach]

Looks like the port name you are entering causes the problem. Could you please download the new nrfmon.tcl and paste what gets printed in the console?

[JohnOH]

I wonder if it is because I didn't use a ":" colon after the COM4.

● nRfMon v0.7a
(C) 2013,D.Zachariadis
Licensed under the GPLv3
. Connected 
● JeeNode.v6 live
. Listening
error reading "file40a4d80": I/O error
. Disconnected
error reading "file40a4d80": I/O error
. Disconnected
. Connected 
● JeeNode.v6 live
. Listening

[JohnOH]

With a colon after the COM4.

● nRfMon v0.7a
(C) 2013,D.Zachariadis
Licensed under the GPLv3
. Connected 
● JeeNode.v6 live
. Listening
error reading "file332d080": I/O error
. Disconnected
error reading "file332d080": I/O error
. Disconnected
█ Not connected
█ Not connected
error reading "file332d080": permission denied
. Disconnected
█ Not connected
. Connected 
● JeeNode.v6 live
. Listening
. Scanning
► 

[dzach]

It looks as if the port name does not correspond to a readable serial port. The initial error was due to TCL parsing the error string as a list. Now that it is parsed as a string the error code shown says that the port is not readable; maybe is already used by another process?

[JohnOH]

I wonder, do you do a new open for the port when changing from Listen to Scan?

[dzach]

No. A new 'open' will show '. Disconnected', '. Connected'. Changing mode will show '. Listening', '. Scanning'. The dot '.' at the beginning indicates a change of state.

So, in the console extract from above, nRfMon is connected to the port, sees the correct reply by the sketch and goes live to the '. Listening' state. After that, something disconnects the port and further interactions cannot happen. That usually happens if the cable is disconnected or if the port changes owner and the new owner does not permit operations.

[JohnOH]

Odd, I did a few switches between Scan & Listen and while I was observing the error message appeared.

Licensed under the GPLv3
█ Not connected
. Connected 
● JeeNode.v6 live
. Listening
. Scanning
. Scanning
. Listening
. Scanning
. Listening
error reading "file41cb9d0": I/O error
. Disconnected
error reading "file41cb9d0": I/O error
. Disconnected
error reading "file41cb9d0": I/O error
. Disconnected
► 

After the error the JeeNode kept on flashing and the Listen display continued.

[dzach]

Then it may be a USB connection issue.

[JohnOH]

Very unusual symptoms:

● nRfMon v0.7a
(C) 2013,D.Zachariadis
Licensed under the GPLv3
. Connected 
error reading "file42e7980": I/O error
. Disconnected
. Listening
error reading "file42e7980": I/O error
. Disconnected
error reading "file42e7980": I/O error
. Disconnected
< 56d
< 11d
< 16d
< 36d
< 181d
< 196d
< 174d
< 89d
< 90d
< 22d
< 0d
< 223d
< 119d
< 232d
< 236d
< 4d
< 207d
< 223d
< 253d
< 196d
< 223d
< 2d
< 48d
< 55d
< 10d
< 216d
< 122d
< 16d
< 56d
< 205d
< 229d
< 37d
< 201d
< 111d
< 145d
< 142d
< 160d
< 10d
< 162d
< 107d
< 240d
< 89d
< 175d
< 198d
< 221d
< 35d
< 209d
< 134d
< 136d
< 38d
< 112d
< 94d
< 192d
< 224d
< 191d
< 196d
< 100d
< 129d
< 56d
█ Not connected
< 220d
< 247d
< 252d
< 49d
< 177d
< 208d
< 99d
< 110d
< 5d
< 194d
< 3d
< 207d
< 112d

[JohnOH]

● nRfMon v0.7a (C) 2013,D.Zachariadis Licensed under the GPLv3 . Connected error reading "file42e7980": I/O error . Disconnected . Listening error reading "file42e7980": I/O error . Disconnected error reading "file42e7980": I/O error . Disconnected < 56d < 11d < 16d < 36d < 181d < 196d < 174d < 89d < 90d < 22d < 0d < 223d < 119d < 232d < 236d < 4d < 207d < 223d < 253d < 196d < 223d < 2d < 48d < 55d < 10d < 216d < 122d < 16d < 56d < 205d < 229d < 37d < 201d < 111d < 145d < 142d < 160d < 10d < 162d < 107d < 240d < 89d < 175d < 198d < 221d < 35d < 209d < 134d < 136d < 38d < 112d < 94d < 192d < 224d < 191d < 196d < 100d < 129d < 56d █ Not connected < 220d < 247d < 252d < 49d < 177d < 208d < 99d < 110d < 5d < 194d < 3d < 207d < 112d

[JohnOH]

The new Win32 binary image executes fine on my Win7x64 machine. I have the same strange 'USB' issues described yesterday.

I note that as soon as the communication port is entered it appears to begin listening. A few lines of pixels are displayed on the waterfall and then there is 10-20 seconds pause when the water fall doesn't change but the JeeNode transmits vigorously. Then in one screen paint the whole of the waterfall is populated and it fills and scrolls 'normally'.

It is difficult to switch into scan mode since it appears very busy listening. Selecting 'disconnect' from the port box appears to work. Perhaps it should default to doing nothing and waiting for the user to select a mode of operation.

[JohnOH]

The compiled version isn't remembering the window position when I change it then exit and restart.

[JohnOH]

I have noticed that if the JeeNode is disconnected and then reconnected; after a few seconds the TX led begins to flash regularly, once every 1-2 seconds. I am using a JeeNode USB V3. This happens before nRFMon is executed. If nRFMon is connected to the port the TX leds flashes swiftly and away we go. If nRFMon is then exited the JeeNode goes quiet and stays quiet until nRFMon is executed again. So, there is a difference in action between a freshly initialised JeeNode and one that has been connected to previously.

[JohnOH]

Perhaps we need an open for business transaction to the JeeNode.

[dzach]

The difference in action between a freshly initialized and a previously connected to node is normal. The rf12mon.ino sketch has a default delay of 10s after it powers up during which it waits for a connection by a host. If this doesn't happen it then starts transmitting with the default settings. This has been in place since the beginning to allow unattended start of transmit for a remote node.

The 'open for business' transaction is there and manifests itself with a ● JeeNode.v6 live message, which shows up in the console.