Tau2 with TeaxGrabber - timeouts in fpa and housing temperatures

[navotoz]

Hello,

I'm using Tau2 with the TeaxGrabber.

get_fpa_temperatures() and get_housing_temperatures() sometimes returns the correct values, and sometimes returns errors such as:

Initial packet byte incorrect. Byte was: 67 Error reply from camera. Try re-sending command, or check parameters.

Initial packet byte incorrect. Byte was: 93 Error reply from camera. Try re-sending command, or check parameters.

Initial packet byte incorrect. Byte was: 0 Error reply from camera. Try re-sending command, or check parameters. .....

I noticed no pattern - sometimes I'm able to get 5 measurements in a row, sometimes it fails after just 1 measurement. I tried adding sleep() between sending to receiving, without results. I tried reconnecting the Tau2, and resetting the PC a couple of times.

Thanks for the great package (again :-))

https://github.com/LJMUAstroecology/flirpy/blob/b48b6434fa1572d833c9c42fd57577983dce903f/flirpy/camera/tau.py#L153-L176

[jveitchmichaelis]

Yep this is currently a bit buggy due to the way the serial stream is implemented. I think it's just losing sync when the messages are sent back from the camera. Not sure if there's an easy fix here without re-writing the stream handling code to be more like a proper state machine.

But we can do the same as before - if you can dump the serial buffer just before the error I can take a look and see if we can figure something out :)

In theory what should happen is when you query the camera, we start looking for a magic string in the buffer and process the response as normal a normal Tau2. By the way in the code, the calls to receive packets are actually overriden by the Teax class.

https://github.com/LJMUAstroecology/flirpy/blob/b48b6434fa1572d833c9c42fd57577983dce903f/flirpy/camera/tau.py#L658-L668

https://github.com/LJMUAstroecology/flirpy/blob/b48b6434fa1572d833c9c42fd57577983dce903f/flirpy/camera/tau.py#L616-L631

As before, we can try changing data = self._read() to data += self._read().

One concern is perhaps we accidentally discard the data before waiting for it.

But.. the problem you're getting isn't a timeout in command sync otherwise you'd get that warning. So it does seems like a packet decode problem - if you can send me a serial dump I'll take a look. The temp read function is pretty well unit tested on the Tau so I would lean towards we're just incorrectly getting data out of the stream, rather than the decoder is wrong.

[navotoz]

I changed to data += self._read() on both functions, without results.

Here are the logs: log_first_fail.txt log_fourth_fail.txt

[jveitchmichaelis]

Can you save the entire data buffer from _sync_uart? (e.g. just before the return - so it should start with "UART")

[navotoz]

log__sync_uart_failed_2.txt log__sync_uart_failed_7.txt Is this what you meant?

[jveitchmichaelis]

Try (as when you had trouble with image capture):

 np.save("dump.dat", data)

just before:

 return data[data.find(magic):] 

But this is interesting, it looks like each byte is packed. Ok should be quite easy to fix this, probably needs a new function that will read out a certain number of UART bytes.

UART\x01nUART\x01\x00UART\x01\x00UART\x01 UART\x01\x00UART\x01\x02UART\x01yUART\x01?UART\x01\x0cUART\x01IUART\x01\x9cUART

I'm curious about the case when this works though... it seems like the format isn't always like that. Maybe this happens when the data are interleaved.

[navotoz]

dump_fail.zip dump_success.zip

[navotoz]

I tried using pickle instead:

import pickle
with open("dump.pkl", "wb") as fp:
    dump(data, fp)

Results: dumps_pickle.zip