uCAM-III Reset ACK after GET_PICTURE

[retry111]

Hi,

I am faced with an odd problem, I get an RESET ACK after a GET_PICTURE CMD @ 115200 baud and 3.3V signaling

[ucam_get_dev] Fetched Command 0xAA0E0D000000 len 6
[process_uinit_state] Got the ACK after 6 attempts
[process_uinit_state] Looking for SYNC from device
[ucam_get_dev] Fetched Command 0xAA0D00000000 len 6
[process_uinit_state] Got the SYNC from device, responding with ACK
[ucam_send_cmd] Sending Command 0xAA0E0D000000
[process_connected_state] Process Connected State
[process_connected_state] INITIAL CMD
[ucam_send_cmd] Sending Command 0xAA0100070707
[ucam_get_dev] Fetched Command 0xAA0E01010000 len 6
[process_connected_state] PACKAGE_SIZE CMD
[ucam_send_cmd] Sending Command 0xAA0608000200
[ucam_get_dev] Fetched Command 0xAA0E06020000 len 6
[process_ready_state] Process Ready State
[process_ready_state] SNAPSHOT CMD
[ucam_send_cmd] Sending Command 0xAA0500000000
[ucam_get_dev] Fetched Command 0xAA0E05030000 len 6
[process_ready_state] GET_PICTURE CMD
[ucam_send_cmd] Sending Command 0xAA0401000000
[ucam_get_dev] Fetched Command 0xAA0E08040000 len 6 <----- Why 0xAA0E08 ????
[process_get_data_state] Process Get Data State
[ucam_get_dev] Fetched Command 0xFFFFFFFFFFFF len 0 <------ Invalid Data
[ucam_get_dev] Fetched Command 0xFFFFFFFFFFFF len 0
[ucam_get_dev] Fetched Command 0xFFFFFFFFFFFF len 0
[ucam_get_dev] Fetched Command 0xFFFFFFFFFFFF len 0
[ucam_get_dev] Fetched Command 0xFFFFFFFFFFFF len 0
[ucam_get_dev] Fetched Command 0xFFFFFFFFFFFF len 0
[ucam_get_dev] Fetched Command 0xFFFFFFFFFFFF len 0
[ucam_get_dev] Fetched Command 0xFFFFFFFFFFFF len 0
[ucam_get_dev] Fetched Command 0xFFFFFFFFFFFF len 0
[ucam_get_dev] Fetched Command 0xFFFFFFFFFFFF len 0
[ucam_get_dev] Fetched Command 0xFFFFFFFFFFFF len 0

[retry111]

Any insight on this issue ?

[Mark Kevin]

Hi retry111,

What is the supply voltage you provide to the uCAM-III?

Did you get these results from the uCAM-III DEMO in the workshop 4 IDE and using a Serial-to-USB converter?

[retry111]

The supply voltage is 5.2V from a power supply. The results were not obtained via the uCAM-III DEMO, it was obtained via an embedded board communicating with the ucam

[Mark Kevin]

Do you have any available Serial-to-USB converter? like the uUSB-PA5?

Can you please simulate the scenario using the uCAM-III demo from the Workshop 4 IDE? Just go to NEW > (on the drop down menu box) OTHER > UCAM-III demo. You will need to connect the uCAM-III to the PC using a Serial-to-USB TTL converter (5V, TX, RX and GND) to send the commands from the uCAM-III demo (PC) to the uCAM-III itself.

We have already simulated and tested this scenario, but we could not get the same results/issue as in your post. Let us try to isolate the uCAM-III if it is indeed faulty.

[retry111]

Using the demo, I got the camera working correctly and producing a photo. I am in the process of trying to compare the waveforms between the demo and my device but this will prove quite arduous. Any "low hanging fruit" I can try? I checked the supply voltage, it's in spec.

[Mark Kevin]

Since we've isolated the problem. I think that you should double-check if your custom board sends/receives the correct serial byte commands. Try using the Serial-to-USB and a serial terminal (you can use the workshop 4 IDE > Tools > Serial Terminal 9600/Serial Terminal 115200) to check your custom board.

[retry111]

So I hooked up two serial cables to the TX and RX of the uCAM to capture what it receives and sends out, below is the output: MASTER TX. Is there any way to check what could be the reason for the reset? Is it possible for the camera to send a RESET ACK without a command prompting it to do so, if so under what circumstances could that happen? Anything else you can think of that I can check?



MASTER RX

[phil.wolff]

I see that there's been no resolution to this problem.

I have exactly the same issue with ucam III.
I have both ucamII and ucamIII.

I have self produced software (running on a PC) sending packets through a Snap wireless network to a remote Snap device attached to the cameras (a different device for each camera)
with the uCamII both my software and the uCamII and uCamIII demo software work perfectly.

With the uCamIII, I replace the uCamII with the uCamIII, when I send the AA 04 01 00 00 00 request and get the AA 0E 08 0x 00 00 reset response.

When I disconnect my software and re-connect both the uCamII and uCamIII demo software, without changing any of the hardware connections, everything works perfectly.
Although I see that both uCamII and uCamIII report that they are sending AA 04 02 00 00 00 NOT (per your documentation) AA 04 01 00 00 00. However if, in my software I attempt to send AA 04 02 00 00 00 I get an 'invalid parameter' error returned from the uCamIII.

Up until the 'get snap shot' request, both your demos and my software agree exactly an what is being sent out and received.

Tomorrow morning I'll capture what your demo software sends and receives to make sure there's not some un-documented command (and undisplayed in your software) that I'm missing.

[John Kevin]

Hello,

Welcome to the forum.

Although I see that both uCamII and uCamIII report that they are sending AA 04 02 00 00 00 NOT (per your documentation) AA 04 01 00 00 00.

Can I confirm that you want to capture the image in 'Snapshot mode'? Please take a look at the attached image.

However if, in my software I attempt to send AA 04 02 00 00 00 I get an 'invalid parameter' error returned from the uCamIII.

I am unsure of how you are doing it at your end. Can you post here the log of your application?


Best Regards,
Kevin

[phil.wolff]

Hi Kevin,

It looks like I wasn't waiting long enough after getting the snapshot ack before sending the get picture command (the uCamIII must be a little slower than the uCamII). Putting in a 100ms delay appears to work, at least for raw images. I'm away from that hardware for the rest of the day, but muck with it again tomorrow morning.

Cheers
Phil.

[John Kevin]

Thank you for letting us know.

[phil.wolff]

Hi John,

Mia culpa, turns out my check for the response to the snapshot command was flawed. The 100ms delay I added covered that flaw (although I still can't work out why the same code worked with the uCamII.

Cheers
Phil.

[John Kevin]

Hello Phil,

I think that it is the only workaround that you can have.

Best Regards,
Kevin