search

OrsayDev / OrsayLaser

Instrumentation for Laser / Blanker / Gain usage in Nionswift
0 stars 0 forks source link

[IMPORTANT] checksum wrong #35

Closed yvesauad closed 4 years ago

yvesauad commented 4 years ago

this is an important issue. Will explain it nicely because it affects precedent measurements.

i've noticed some slowness in my software, which i was attributing to any of my hardwares. I've reduced timeout to 100ms to see if any hardware had a lazy response.

Turns out it was not slow but in fact laser WL was not properly set for a range of available WL because checksum of laser communication was wrongly done.

Example: 571 nm: bytes = [60, 7, 1, 10, 247, 19, 0, 0, 0, 0, 0, 88, 62] checksum = 60 + 7 + 1 + 10 + 247 + 19 = 344 of course we are working with bytes so your checksum must be 344 - 256 = 88 (0x58) this reduction is covered!!! laser responds perfectly

571.50 nm: bytes = [60, 7, 1, 253, 242, 19, 0, 0, 0, 0, 0, CHECKSUM, 62] checksum = 60 + 7 + 1 + 253 + 242 + 19 = 582 i was for some reason ignoring that 582 - 256 = 326 could still be > 255 so i was trying to send an inexistant byte.

super stupid and i have not much idea of the impact of this. All my other measurements are based on a good laser step progression. Note however that i have all raw data which includes my bad measurements. If you wanna know if a measurement is bad, just look at LASER WAVELENGTH data_item in nionswift. It must be there.

solution: checksum = checksum - 256 * int(checksum/256)

for checksum = 255, checksum = 255
for checksum = 256, checksum = 0
for checksum = 344,  checksum = 88
for checksum = 582, checksum = 70
yvesauad commented 4 years ago

solved. Way better. Inoticed how i never could put my laser in 571.5 before...