add byonoy luminescence and absorbance plate readers #617
Conversation
rickwierenga
changed the title
rickwierenga
force-pushed
the
byonoy-luminescence
branch
from
1c31283 to
8f25dbf
Compare
rickwierenga
force-pushed
the
byonoy-luminescence
branch
from
300934e to
581d659
Compare
rickwierenga
force-pushed
the
main
branch
5 times, most recently
from
49a6770 to
159fd78
Compare
| if self._sending_pings: | ||
| # fluor uses this. however, the absorbance one also works for fluor. | ||
| # cmd = "40000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008040" | ||
| cmd = "0040000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040" |
There was a problem hiding this comment.
This is the correct heartbeat message common to all devices. While this is technically optional, I do highly recommend keeping it in. You should however also send the command to disable the heartbeat when shutting down. It's the same message, just replace the 1 with a 0. Otherwise, the device hits a watchdog timer and reboots a couple of seconds after PLR drops the connection. Nothing critical, just nicer because otherwise users might get the Windows device disconnect/connect chimes.
There was a problem hiding this comment.
thanks for clarifying!
what's the difference with the last 2 bytes: 0x8040 vs 0x0040?
There was a problem hiding this comment.
answering my own question: you mentioned the last 2 bytes are routing information and it's best to set them to 0
| "0000020700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008040" | ||
| ) | ||
| ) | ||
| # above this it checks if absorbance is supported. which command? |
There was a problem hiding this comment.
None of them. The commands ask the device, what subset of the communication protocol it supports, what version of the protocol it understands, and finally what the content of data field 7 is. Which is QUEUE_DEPTH, the supported number of parallel requests the device can handle. For your purpose the USB VID/PID should be enough to assume the device supports the associated measurement method.
There was a problem hiding this comment.
ah interesting, I had seen in your sdk there is a check for whether absorbance is supported, but this must be done by pidvid then. thank you for sharing what those methods mean.
It should be safe to delete them here right?
| ), | ||
| wait_for_response=False, | ||
| ) | ||
| self._stop_background_pings() |
There was a problem hiding this comment.
This command sequence here is:
- Status request
- Absorbance measurement trigger
- Heartbeat
- Status request
- Status request
- Read data field 7
- Absorbance measurement trigger
- Heartbeat
Most of this should not be necessary. You ignore the status and data field replies, you have the heartbeat running in a background process anyway, and one measurement trigger should be enough.
There was a problem hiding this comment.
Interestingly this is exactly what I observe when packet sniffing your sdk (and I believe I only read data once there), but very much down to make the implementation more efficient :) thanks!
|
|
||
| if ( | ||
| bytes.fromhex( | ||
| "30000000000034000000526573756c74732020546f7020526561646f75740a0a0000000000000000000000000000000000000000000000000000000000000000" |
There was a problem hiding this comment.
This is a diagnostic message: "Results Top Readout"
Diagnostics are subject to change and this one in particular changes depending on the physical device orientation during readout. It would be better to listen for the REP_LUM96_MEASUREMENT_IN (0x0600) messages instead.
There was a problem hiding this comment.
REP_LUM96_MEASUREMENT_IN (0x0600)
where in the message would I expect to see 0x0600?
is there an overview of all messages that are supported?
rickwierenga
force-pushed
the
main
branch
2 times, most recently
from
bffeb24 to
a1d61b7
Compare
absorbance will follow soon
todo: