Data transfer was incomplete.

[rach8cww]

I'm having an issue while reading the histogram from my device:

Trying to connect to instrument ttyACM0 ...
Connected to instrument! <usbiss.spi.SPI object at 0x76a49710>
Connected to Alphasense OPC-N2v18.2
Device status:
{'LaserDACVal': 1, 'FanDACVal': 1, 'FanON': 1, 'LaserON': 1}
Turning laser and fan on... Done.
Device status:
{'LaserDACVal': 1, 'FanDACVal': 1, 'FanON': 1, 'LaserON': 1}
----------------------------------------------------------------------
         Failed while retrieving results
Could not load histogram
----------------------------------------------------------------------

/home/pi/.local/lib/python3.5/site-packages/opc/__init__.py:522: UserWarning: Data transfer was incomplete.
  warnings.warn("Data transfer was incomplete.")

Any ideas on what the issue could be?

[tavurth]

https://github.com/rach8cww/OPC_Work

[DancingQuanta]

Does that happen every time you tried to get the histogram?

[rach8cww]

Yes it does

[dhhagan]

Could you let us know which version of the library you are using, as well as what version of Python, and what firmware version of the OPC-N2 you are using?

[rach8cww]

Hi dhhagan, I was using the pyusbiss library using a simple pip3 install with python 3 and the OPC-N2 firmware version I have is 18.2.

[DancingQuanta]

What version of pyusbiss are you using?

On Sat, 12 May 2018, 09:20 rach8cww, notifications@github.com wrote:

Hi dhhagan, I was using the pyusbiss library using a simple pip3 install with python 3 and the OPC-N2 firmware version I have is 18.2.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dhhagan/py-opc/issues/66#issuecomment-388539285, or mute the thread https://github.com/notifications/unsubscribe-auth/AIB3VT-VjbN5cx5RCIQy1cW-ym3wagWSks5txptfgaJpZM4T79Uu .

[rach8cww]

Sorry for the delay, I'm using pyusbiss 0.2.2

[DancingQuanta]

Can you try pyusbiss 0.2.0?

On Sun, 13 May 2018, 16:00 rach8cww, notifications@github.com wrote:

Sorry for the delay, I'm using pyusbiss 0.2.2

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dhhagan/py-opc/issues/66#issuecomment-388633259, or mute the thread https://github.com/notifications/unsubscribe-auth/AIB3VU42E_rP1q158QbC43s4tCAVxAfzks5tyEpygaJpZM4T79Uu .

[rach8cww]

pi@raspberrypi:~/project $ pip3 freeze | grep -i 'py-opc\|pyusbiss'
py-opc==1.5.0
pyusbiss==0.2.0

Still no luck, fails with the same error message:

/home/pi/.local/lib/python3.5/site-packages/opc/__init__.py:522: UserWarning: Data transfer was incomplete.

Could this be an issue with my device?

[rach8cww]

Solved the issue - the instrument needs to have time to warm up before you ask for the histogram. I've added a few short sleep pauses in as well and is makes it run smoother. This is the output now:

Trying to connect to instrument ttyACM0 ... Connected to instrument! <usbiss.spi.SPI object at 0x76a23cf0> Connected to Alphasense OPC-N2v18.2 Alphasense instrument processing request

Device status: {'FanON': 1, 'LaserDACVal': 1, 'FanDACVal': 1, 'LaserON': 1} Device status: {'FanON': 4, 'LaserDACVal': 4, 'FanDACVal': 4, 'LaserON': 4}

2018-06-21 14:29:17 Key: PM2.5 Value: 0.29654639959335327 Key: Bin 6 Value: 0.02371237245465762 Key: Pressure Value: None Key: Bin7 MToF Value: 11.666666666666666 Key: Bin 12 Value: 0.0 Key: Bin 10 Value: 0.0 Key: Bin 1 Value: 0.02371237245465762 Key: Bin 0 Value: 0.08299330359130166 Key: PM1 Value: 0.08018143475055695 Key: Bin 3 Value: 0.01185618622732881 Key: Bin3 MToF Value: 21.0 Key: Bin 8 Value: 0.03556855868198643 Key: Bin 4 Value: 0.01185618622732881 Key: Bin 11 Value: 0.0 Key: Checksum Value: 25 Key: Temperature Value: None Key: PM10 Value: 2.543792486190796 Key: Bin 5 Value: 0.03556855868198643 Key: Bin1 MToF Value: 12.666666666666666 Key: SFR Value: 2.678318738937378 Key: Sampling Period Value: 31.491455078125 Key: Bin 13 Value: 0.0 Key: Bin 9 Value: 0.02371237245465762 Key: Bin 14 Value: 0.0 Key: Bin 15 Value: 0.0 Key: Bin5 MToF Value: 12.333333333333334 Key: Bin 2 Value: 0.03556855868198643 Key: Bin 7 Value: 0.01185618622732881

2018-06-21 14:29:19 Alphasense OPC-N2v18.2 - Instrument finished getting data

[dhhagan]

@rach8cww Great to hear! I'll be sure to add a note to the docs about waiting a bit between commands. I did speak with Alphasense and they mentioned this may be a requirement...

[DancingQuanta]

Does alphasense have some more details on timings for each i2c commands and probably timing diagrams?

On Fri, 22 Jun 2018, 02:38 David H Hagan, notifications@github.com wrote:

@rach8cww https://github.com/rach8cww Great to hear! I'll be sure to add a note to the docs about waiting a bit between commands. I did speak with Alphasense and they mentioned this may be a requirement...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dhhagan/py-opc/issues/66#issuecomment-399293912, or mute the thread https://github.com/notifications/unsubscribe-auth/AIB3VfcbL860lSyxnrmVSiScELLrMwx9ks5t_EqNgaJpZM4T79Uu .

[dhhagan]

@DancingQuanta They do not - it's quite unfortunate. I do have quite a few screenshots (and data) for most of the commands via a Logic Analyzer, but that's about it. In addition, some of the commands aren't designed to actually be functional, which they say will be fixed on the OPC-N3 (i.e. the laser_off command doesn't actually do anything).

[DancingQuanta]

Ah well that is a shame. Looks like we have to figure out what works. What will your strategy be regarding issues raised here?

On Fri, 22 Jun 2018, 15:22 David H Hagan, notifications@github.com wrote:

@DancingQuanta https://github.com/DancingQuanta They do not - it's quite unfortunate. I do have quite a few screenshots (and data) for most of the commands via a Logic Analyzer, but that's about it. In addition, some of the commands aren't designed to actually be functional, which they say will be fixed on the OPC-N3 (i.e. the laser_off command doesn't actually do anything).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dhhagan/py-opc/issues/66#issuecomment-399459525, or mute the thread https://github.com/notifications/unsubscribe-auth/AIB3VYbKwaoD4WFA89dJafLIIMS-ySnJks5t_P26gaJpZM4T79Uu .

[tavurth]

I'd suggest creating a method, which simply checks every 200ms until the device is ready.

alpha = opc.OPCN2(spi, debug=True).await()

alpha = opc.OPCN2(spi, debug=True, await=True, check=200)

[dhhagan]

@tavurth That sounds like a fantastic idea, though I'm not sure exactly how to implement it with this device. Do you have any thoughts?

[tavurth]

@dhhagan Sure, I made a quick PR

Unfortunately I'm not able to test this, as I don't have the device myself. @rach8cww Could you try the modified code?

Named wait since await is reserved in newer Pythons

[DancingQuanta]

I have an idea. Can histogram and others check the bytes as they come in. If the Alphasense is not ready then when you read in byte they comes as \x01. It would be useful to confirm that byte does not occur at first byte of correct response. So if you detect \x01 then you could repeat the command byte and test again.

[tavurth]

@DancingQuanta That would be perhaps preferable:

        command = 0x30

        # Send the command byte
        self.cnxn.xfer([command])

        # Wait 10 ms
        sleep(10e-3)

        # read the histogram
        for i in range(62):
            r = self.cnxn.xfer([0x00])[0]
            resp.append(r)

Here we see that we send a command byte, and then expect to read 62*uint16bit of information.

1) Can we cancel that query by just sending another command byte? (Perhaps we have to read until the end of the 62 bits) 2) How can we make this work for something other than histograms?

I'd be wary about interfacing with the bits directly as we have a good interface to work off of here, built by @dhhagan. However if it's more stable, or extensible, then we should certainly do so.

Perhaps you could comment on the above two questions if you have more information?

[DancingQuanta]

Alas, I do not know the details of Alphasensw’s spi. The code snippet you have shown is common in this library and the number of byte read back varies. As someone who likes to see more functions than repeating patterns, I suggest this snippet be encapsulated in a function with two or three arguments for a byte command and number of reads and maybe a time period for sleep.

On other note, I noticed that this library already have a ping function, this sends one byte and read back one byte so pretty efficient way of checking the device is ready, compared with your wait method.