QHYCCD

Odd behavior of QHYCFW3-M with QHY268M

Odd behavior of QHYCFW3-M with QHY268M
« on: April 02, 2021, 02:03:52 PM »
I have a new QHY268M and QHYCFW3-M. The filter wheel is acting odd. It was connected to the camera via the 4-pin connector.

I run both from Linux using the QHY SDK directly, and had no problems at all the first two weeks. Then, the SDK started giving an error response to IsQHYCCDCFWPlugged(). Looking at the debugging output from the SDK shows:
QHYCCD|QHY5IIICOOLBASE.CPP|IsCFWPlugged|IsCFWPlugged
QHYCCD|QHYCAM.CPP|vendTXD|call vendTXD_Ex
QHYCCD|QHYCAM.CPP|vendTXD_Ex|req 0xc1 index 0x0 value 0x0 length 3
QHYCCD|QHYCAM.CPP|vendRXD|call vendRXD_Ex
QHYCCD|QHYCAM.CPP|vendRXD_Ex|req 0xc3 index 0x0 value 0x0 length 8
QHYCCD|QHYCAM.CPP|vendRXD_Ex|RXD Transfer Error CODE=-1
QHYCCD|QHYCCD.CPP|IsQHYCCDCFWPlugged|ret -1


I shifted the CFW over to a direct USB connection (changing the switch on the CFW itself). I found that the CFW responds perfectly to the USB filter selection commands ('0' through '6'), rotating the wheel correctly and echoing back the selected filter number when the wheel stops. But the CFW does not give any response to the three multi-character commands ("VRS", "MXP", and "NOW"). (It looks like the SDK wants a valid response to the VRS command during processing of the IsQHYCCDCFWPlugged query.)

I uploaded the most recent firmware into the CFW (20181114.hex), but that didn't seem to change anything. Does this sound like an unusual mode for the CFW? Is there any way to do a reset of the CFW beyond a power-on-reset or beyond reloading the firmware?

- Mark M

Re: Odd behavior of QHYCFW3-M with QHY268M
« Reply #1 on: April 05, 2021, 09:17:41 PM »
Hi,
    I need check this issue,please wait for some time,and if you try it on Windows,does it still have same SDK and USB issue?
Best Regards,
QinXiaoXu

Re: Odd behavior of QHYCFW3-M with QHY268M
« Reply #2 on: April 06, 2021, 03:11:55 PM »
Hi, QinXiaoXu:
I tried it on Windows via USB, and it behaved the same as on Linux via USB (change filter slot commands worked fine, but no response to the 3-letter commands). I haven't been able to build a Windows app yet with the SDK (I'm not very good compiling Windows programs), but I tried EZCAP_QT under Windows. It doesn't look like EZCAP tests the CFW connection the same as the SDK does with the IsQHYCCDCFWPlugged() query. EZCAP did not move the filter wheel, and generated the following debug output:
00000173   13.58931637   [9268] QHYCCD|QHY5IIICOOLBASE.CPP|GetCFWStatus|GetCFWStatus   
00000174   13.58950043   [9268] QHYCCD|QHYCAM.CPP|vendTXD|call vendTXD_Ex   
00000175   13.58954906   [9268] QHYCCD|QHYCAM.CPP|vendTXD_Ex|req 0xc1 index 0x0 value 0x0 length 3   
00000176   13.69811726   [9268] QHYCCD|QHYCAM.CPP|vendRXD|call vendRXD_Ex   
00000177   13.69821739   [9268] QHYCCD|QHYCAM.CPP|vendRXD_Ex|req 0xc3 index 0x0 value 0x0 length 1   
00000178   13.69919205   [9268] QHYCCD|QHYCAM.CPP|vendRXD_Ex|Warning:RXD Transfer Return False vendcommand=0xc3   
00000179   13.69929409   [9268] QHYCCD|QHYCAM.CPP|vendRXD_Ex|Warning----> CODE=-1 usbd=0   [state=SUCCESS status=USBD_STATUS_SUCCESS]    
00000180   13.69938850   [9268] QHYCCD|QHYCCD.CPP|dataEvent.error| Calling   
00000181   13.70090199   [9268] QHYCCD|QHYCAM.CPP|vendRXD_Ex|Warning:No vendor request exist in firmware or return 0 by this vendrequest   
00000182   13.70101166   [9268] QHYCCD|QHY5IIICOOLBASE.CPP|GetCFWStatus|GetCFWStatus - vendRXD success   
00000183   13.70110703   [9268] QHYCCD|QHYCCD.CPP|GetQHYCCDCFWStatus|status[0] N

- Mark

Re: Odd behavior of QHYCFW3-M with QHY268M
« Reply #3 on: April 06, 2021, 08:37:53 PM »
Hi,
    It seem a hardware issue,but I'm not sure it is because of 4PIN cable or CFW itself.
    Normally,CFW can response all command("VRS","MXP","NOW") in 4PIN or USB mode.Do you have other 4PIN cable or camera test it?
    And how do you send the command?Send "VRS" in one time or send "V" "R" "S" in three times?
Best Regards,
QinXiaoXu

Re: Odd behavior of QHYCFW3-M with QHY268M
« Reply #4 on: April 08, 2021, 07:30:44 PM »
I'm now fairly convinced that this is a software issue. I checked continuity of the 4-pin cable, and it tests okay. I went back to the USB control of the filter wheel, and got it to work correctly. What I learned:
  • Whenever the CFW goes through its initialization sequence (for example, if the interface is closed and then reopened), at the end of the initialization sequence the CFW will send an unsolicited single character '0'. My CFW sends the '0' response code approximately 18 seconds after the initialization sequence begins.
  • Any commands sent to the CFW before the initialization sequence ends can mix up the CFW. Sometimes the commands will be processed after the initialization sequence finishes, but sometimes the CFW will go into a "silent" mode where it will not respond to any further commands until another initialization occurs. It seems important to never send a command to the CFW before the CFW finishes its initialization and sends the initialization-complete '0'. The SDK does not enforce this.
  • The 3-character commands cannot be sent spread over time. There is a maximum time allowed for the sending of the three characters, measured in milliseconds. If you exceed this maximum time, the CFW will silently ignore the 3-character command.
  • It is relatively easy to lose "synchronization" with the CFW, by leaving a character response "stuck" in a UART buffer somewhere in the communications path. (For example, this is easily triggered by failing to flush (read) the unsolicited response to the initialization sequence.) When this happens, the device sending commands will read the response from an earlier CFW command, thinking it is the response to the most recent CFW command.
I still haven't been able to get the 4-pin connector interface to the camera to work properly, but I strongly suspect that it's because I'm not triggering the correct sequence/timing of commands from the camera to the CFW. I notice that the INDI source code (which works the CFW through the camera) has some features that suggest to me that the camera-to-CFW interface can sometimes lose synchronization.
However, because I can now control the CFW cleanly via the USB interface, I no longer have a problem. I'll just use the USB interface.
- Mark
« Last Edit: April 08, 2021, 07:33:19 PM by Mark.Munkacsy »