get_analyzers raises IndexError

[jmsaarenbf]

I have everything running under Debian 10. Logic Pro 16 is connected and I have Logic 1.2.18. When I run the sample code below:

#!/bin/python3
import saleae
import time
s = saleae.Saleae()
s.close_all_tabs()
s.set_active_channels(digital=range(16))
s.set_trigger_one_channel(1,saleae.Trigger.NoTrigger)
s.set_capture_seconds(1)
s.set_sample_rate(s.get_all_sample_rates()[0])
s.capture_start()
time.sleep(1)
while True:
    if s.is_processing_complete():
        break
    time.sleep(0.1)
print(s.get_analyzers())

I get:

Traceback (most recent call last):
  File "test.py", line 28, in <module>
    print(s.get_analyzers())
  File "/home/tester/.local/lib/python3.7/site-packages/saleae/saleae.py", line 1014, in get_analyzers
    analyzer_index = int(line.split(',')[1])
IndexError: list index out of range

The content of the line in saleae.py should have been:
I2C, 1
instead I get:
TRUE
and then the library raises an index error.

[ppannuto]

Can you capture a trace with more verbose logging? i.e. at the start

import logging
logging.basicConfig(level=logging.DEBUG)

should show what's going on in the underlying communication protocol

[jmsaarenbf]

INFO:saleae.saleae:Connected.
DEBUG:saleae.saleae:Send >CLOSE_ALL_TABS<
DEBUG:saleae.saleae:Recv >ACK<
DEBUG:saleae.saleae:Send >GET_CONNECTED_DEVICES<
DEBUG:saleae.saleae:Recv >1, Logic Pro 16, LOGIC_PRO_16_DEVICE, 0x85e0d350d7673c58, ACTIVE
ACK<
DEBUG:saleae.saleae:Send >GET_CONNECTED_DEVICES<
DEBUG:saleae.saleae:Recv >1, Logic Pro 16, LOGIC_PRO_16_DEVICE, 0x85e0d350d7673c58, ACTIVE
ACK<
DEBUG:saleae.saleae:Send >SET_ACTIVE_CHANNELS, digital_channels, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15<
DEBUG:saleae.saleae:Recv >ACK<
DEBUG:saleae.saleae:Send >GET_CONNECTED_DEVICES<
DEBUG:saleae.saleae:Recv >1, Logic Pro 16, LOGIC_PRO_16_DEVICE, 0x85e0d350d7673c58, ACTIVE
ACK<
DEBUG:saleae.saleae:Send >GET_ACTIVE_CHANNELS<
DEBUG:saleae.saleae:Recv >digital_channels, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, analog_channels
ACK<
DEBUG:saleae.saleae:Send >SET_TRIGGER, , , , , , , , , , , , , , , , <
DEBUG:saleae.saleae:Recv >ACK<
DEBUG:saleae.saleae:Send >SET_CAPTURE_SECONDS, 1.0<
DEBUG:saleae.saleae:Recv >ACK<
DEBUG:saleae.saleae:Send >GET_ALL_SAMPLE_RATES<
DEBUG:saleae.saleae:Recv >125000000, 0
100000000, 0
50000000, 0
25000000, 0
20000000, 0
12500000, 0
10000000, 0
6250000, 0
5000000, 0
4000000, 0
2500000, 0
2000000, 0
1000000, 0
ACK<
DEBUG:saleae.saleae:Send >GET_ALL_SAMPLE_RATES<
DEBUG:saleae.saleae:Recv >125000000, 0
100000000, 0
50000000, 0
25000000, 0
20000000, 0
12500000, 0
10000000, 0
6250000, 0
5000000, 0
4000000, 0
2500000, 0
2000000, 0
1000000, 0
ACK<
DEBUG:saleae.saleae:Send >SET_SAMPLE_RATE, 125000000, 0<
DEBUG:saleae.saleae:Recv >ACK<
DEBUG:saleae.saleae:Send >CAPTURE<
DEBUG:saleae.saleae:Send >IS_PROCESSING_COMPLETE<
DEBUG:saleae.saleae:Recv >NAK<
DEBUG:saleae.saleae:Send >IS_PROCESSING_COMPLETE<
DEBUG:saleae.saleae:Recv >NAK<
DEBUG:saleae.saleae:Send >IS_PROCESSING_COMPLETE<
DEBUG:saleae.saleae:Recv >NAK<
DEBUG:saleae.saleae:Send >IS_PROCESSING_COMPLETE<
DEBUG:saleae.saleae:Recv >ACKTRUE
ACK<
DEBUG:saleae.saleae:Send >IS_PROCESSING_COMPLETE<
DEBUG:saleae.saleae:Send >GET_ANALYZERS<
DEBUG:saleae.saleae:Recv >TRUE
ACKSPI, 1
SPI, 2
I2C, 3
I2C, 4
ACK<
Traceback (most recent call last):
  File "test2.py", line 20, in <module>
    print(s.get_analyzers())
  File "/home/tester/.local/lib/python3.7/site-packages/saleae/saleae.py", line 1014, in get_analyzers
    analyzer_index = int(line.split(',')[1])
IndexError: list index out of range

[ppannuto]

DEBUG:saleae.saleae:Send >IS_PROCESSING_COMPLETE<
DEBUG:saleae.saleae:Recv >ACKTRUE
ACK<

That looks like a bug on Logic's end, I don't think that is a valid response to that command, @Marcus10110 any insight?

[patricktlo]

I had the same problem and found a workaround slightly modifying the capture_start to block the code. So, capture_start:

def capture_start(self): self._cmd('CAPTURE', False)

Becomes:
def capture_start(self): self._cmd('CAPTURE')

My guess is that once the capture is finished in 'unblocking' mode, it sends an extra ACK and it breaks the flow of the rest of the code.

I could also verify this sending sending a capture_stop() before the capture is finished (in unblocking mode), since the capture is stopped, no ACK is sent by the unblocking capture_start and the code works.

Edit: I just read the other issues and I believe the cause of this issue is explained in #18