This should probably just softly fail that port and continue with a warning/error for the unconnected port.

from faraday-software.

Yes, that would make it much easier for a user who has two units but is switching between one or two of them connected to the computer.

from faraday-software.

Master Commit branched: 2f05998

Testing this out with the following configuration:

[FLASK]
HOST=127.0.0.1
PORT=8000

[PROXY]
UNITS=2

[UNIT0]
CALLSIGN = KB1LQC
NODEID = 1
COM = COM42
BAUDRATE = 115200
TIMEOUT = 5

[UNIT1]
CALLSIGN = KB1LQC
NODEID = 2
COM = COM13
BAUDRATE = 115200
TIMEOUT = 5

Proxy appears to start up fine with this output when I print the units parameter variable in uart_worker() on line 44 of proxy.

2017-02-23 00:47:30,930 - Proxy - INFO - Starting proxy server
2017-02-23 00:47:30,996 - Proxy - INFO - Connected to Faraday
2017-02-23 00:47:31,002 - Proxy - INFO - Starting uart_worker thread
2017-02-23 00:47:31,026 - Proxy - INFO - {u'UNIT1': {u'baudrate': 115200, u'callsign': u'KB1LQC', u'com': u'COM13', u'nodeid': u'2', u'timeout': 5}, u'UNIT0': {u'baudrate': 115200, u'callsign': u'KB1LQC', u'com': u'COM42', u'nodeid': u'1', u'timeout': 5}}

It appears both units are represented. This confirms that my setup is correct and all is well.

Removing One Unit

Removing COM42 USB cable (KB1LQC-1) while Proxy was running resulted in the following error:

Exception in thread Thread-9:
Traceback (most recent call last):
  File "C:\python27\lib\threading.py", line 801, in __bootstrap_inner
    self.run()
  File "C:\Users\Bryce\Documents\GitHub\Faraday-Software\proxy\faraday_uart_stack\layer_2_protocol.py", line 76, in run
    if((self.ser.inWaiting()>0)):
  File "C:\python27\lib\site-packages\serial\serialutil.py", line 538, in inWaiting
    return self.in_waiting
  File "C:\python27\lib\site-packages\serial\serialwin32.py", line 254, in in_waiting
    raise SerialException('call to ClearCommError failed')
SerialException: call to ClearCommError failed

• This should not error and should fail gracefully. @kb1lqc

That said, let's try to start it up again with COM42 cable removed:

2017-02-23 00:53:48,839 - Proxy - INFO - Starting proxy server
2017-02-23 00:53:48,865 - Proxy - ERROR - StandardError: could not open port 'COM42': WindowsError(2, 'The system cannot find the file specified.')
2017-02-23 00:53:49,867 - Proxy - ERROR - StandardError: could not open port 'COM13': WindowsError(5, 'Access is denied.')

Yes this is also bad, it appears that COM42 wasn't found and blocks COM13 from operating. This should absolutely fail gracefully into an operational COM13.

from faraday-software.

OK tracing this it appears that we are not correctly catching a serial exception inside the UART modules. These should be updated sometime in a massive cleanup effort knowing what we know now but they work (and definitely served us well so far).

Line 31 of protocol.py defines the class which initializes a serial object on Line 32:

    def __init__(self, com, baud,timeout_time):
        self.ser = serial.Serial(com, baud, timeout = timeout_time)
        self.serial_rx_queue = Queue.Queue() # Infinite
        self.serial_tx_queue = Queue.Queue() # Infinite
        self.enabled = True

        #Start
        threading.Thread.__init__(self)
self.start() #Starts the run() function and thread

What should happen here is a try/except on the serial.SerialException

from faraday-software.

Digging into this the problem is clearly in the layer_2_protocol(threading.Thread) class.

I added python threading stop() and stopped() functions as suggested when closing a thread (since it fails to connect) and this helped mitigate the issue some.

    def abort(self):
        self.enabled = False
        print "Aborting Layer 2 Class Main"
        self.stop()

    def stop(self):
        self._stop.set()

    def stopped(self):
        return self._stop.isSet()

I also had to go down to the run() function and place a try/except here for each heck for RX data. Only then could I start up Proxy with a unit not attached. Telemetry worked when I pointed it at the relevant Faraday radio.

2017-02-23 01:20:36,812 - Proxy - INFO - Connected to Faraday
2017-02-23 01:20:36,812 - Proxy - INFO - Starting uart_worker thread
2017-02-23 01:20:36,819 - Proxy - INFO - {u'UNIT1': {u'baudrate': 115200, u'callsign': u'KB1LQC', u'com': u'COM13', u'nodeid': u'2', u'timeout': 5}, u'UNIT0': {u'baudrate': 115200, u'callsign': u'KB1LQC', u'com': u'COM42', u'nodeid': u'1', u'timeout': 5}}
2017-02-23 01:21:08,638 - Proxy - ERROR - KeyError: Callsign 'KB1LQC-1' or Port '5' does not exist

I just committed these to my test branch issue62

from faraday-software.

Confirming @kb1lqd that both units currently work with the latest issue62-2 branch per PR #195 comments:

• Even though I specified --unit 1 both started. This is because the unit option deals with which unit to program not run.
• The --number NUMBER option is a control for starting from UNIT0 and counting up. Currently there is no way to ONLY run UNIT1 for example.

from faraday-software.

I also confirmed that if you removed the USB cabled from UNIT0 while both units are running, UNIT1 will continue to work!

Confirmed vice versa:

from faraday-software.

Finally confirming that if I remove UNIT1 and start proxy we exit the program even though UNIT0 is still connected.

I'll think about this and try a solution. It might come down to warning the user about the situation of a misconfiguration based on the hardware present instead of booting just one unit.

from faraday-software.

Proxy Configuration

[FLASK]
host = 127.0.0.1
port = 8000

[DATABASE]
filename = log.db
schemaname = db.sql

[TESTDATABASE]
filename = log.test.db

[PROXY]
log = 0
units = 2
testmode = 0
testrate = 1
testcallsign = REPLACEME
testnodeid = REPLACEME

[UNIT0]
callsign = kb1lqc
nodeid = 10
com = COM24
baudrate = 115200
timeout = 5

[UNIT1]
callsign = kb1lqc
nodeid = 11
com = COM23
baudrate = 115200
timeout = 5

COM24 ONLY

Successfully starts up COM24 KB1LQC-10 and gracefully exits the attempt to start operation COM23 KB1LQC-11

• Confirmed that KB1LQC-11 is available via browser GET request to Proxy

COM23 ONLY

Successfully starts up COM23 KB1LQC-11 and gracefully exits the attempt to start operation COM24 KB1LQC-10

• Confirmed that KB1LQC-10 is available via browser GET request to Proxy

Conclusion

I believe this fixes @kb1lqd's comments in PR #195 with the changes in 37b0100

from faraday-software.

Issue addressed in Merge of PR #195

from faraday-software.