@SIYI : My camera is upside down (on top of vehicle). Here is the behavior I observe: after power up, the camera streams upside-down video, as if it thinks it’s mounted on the bottom of a vehicle. As soon as I start feeding it Set_Gimbal_Control_Angle commands, the image flips to the correct orientation. You can see this at the 00:08 second mark in this video:
Do you get the video stream from RTSP or SIYI protocol?
Thank you Frank. The video I posted is from RTSP. I installed testing 0.2.5. I see the same behavior as before. Video starts upside down and flips after I start driving the gimbal.
Ari.
Frank, I’m noticing packets coming back from the gimbal that I don’t know how to interpret.
Sometimes, but not always, I get get packets of type 0x05 (manual zoom) in response to 0x0F (absolute zoom).
Sometimes, but not always, I get 0x05 in response to 0x0E (set gimbal angle)
Sometimes, I get two packets 0x0E and an 0x0F in the same UDP datagram (the error says invalid length, since it assumes that everything in the datagram is one long packet)
Here’s a portion of a log of me trying to talk to the camera over UDP. -> indicates packets I’m sending to the camera; <- indicates camera’s responses.
-> 556601040000000e 0000d1fe2fef
<- 5566020600c2040e 3f014c05010019c6
-> 556601020000000f 06071157
<- 5566020100c3040f 017ca7
-> 556601040000000e 0800d1feec6a
<- 55660202004e0205 35002c4b
# ^ response CMD ID 0X05 different from request CMD ID 0X0E:CMD_ID.SET_GIMBAL_CONTROL_ANGLE
-> 556601020000000f 06071157
<- 55660202004f0205 36002eb4
# ^ response CMD ID 0X05 different from request CMD ID 0X0F:CMD_ID.ABSOLUTE_ZOOM_AUTO_FOCUS
-> 556601040000000e 1000d1fe88f4
<- 5566020600c4040e 32015c05010075c9 5566020100c5040f 01e580
# ^ invalid data length 6 in 5566020600c4040e 32015c05010075c9 5566020100c5040f 01e580, found 17
-> 556601020000000f 06071157
<- 5566020200500205 3b00d1a3
# ^ response CMD ID 0X05 different from request CMD ID 0X0F:CMD_ID.ABSOLUTE_ZOOM_AUTO_FOCUS
-> 556601040000000e 1800d1fe4b71
<- 5566020200510205 3d0026a3
# ^ response CMD ID 0X05 different from request CMD ID 0X0E:CMD_ID.SET_GIMBAL_CONTROL_ANGLE
-> 556601020000000f 06071157
<- 5566020200520205 3f00962b
# ^ response CMD ID 0X05 different from request CMD ID 0X0F:CMD_ID.ABSOLUTE_ZOOM_AUTO_FOCUS
Please do a small test if the sent package matches the received package
How would that be different from what I posted? I posted sent and received packets, in hex. You can see the first two pairs match (0x0E/0x0E, 0x0F/0x0F). The third pair doesn’t match (0x0E/0x05), and so forth. This is an actual log of my communications with the camera.
Ari.
When you send 0x0f, it replies both 0x0f and 0x05. Because the absolute zoom is accomplished based on manual zoom
Could be a mistake that we cannot reproduce it on our side.
Maybe the mistake occurred when you try to grasp the content?
SIYI protocol makes a clear rule to the data length. Each byte is fixed after reading the initial byte to avoid the mistake like invalid length. And it will be clear when the camera sends multiple commands
First of all, I don’t see anywhere in the documentation that the response to 0x0F is two separate packets. The PDF simply says the response packet is one byte of success or failure. More importantly, I think it’s a really good idea to keep a one-to-one correspondence between requests and responses. Implementing a synchronous protocol is an order of magnitude cheaper and more reliable.
On a serial port, the application has to read packets one byte at a time and find the boundaries between packets, using headers and byte lengths. With UDP, each datagram provides a natural encapsulation for a packet. My assumption until now has been that one UDP datagram represents one packet. Up until this recent update, this assumption has held pretty well.
Hi @SIYI ! I wanted to ask if it is possible to use the Siyi FPV app on an Android device in parallel with the Siyi version of QGC. I am running the Herelink and the second Android device connected together through a router. The router has a manual route set for the internal Herelink IP. I was able to see a stream both on the Herelink and on the FPV app in the same time with the v0.2.6 of the Camera Firmware, without many issues. The SIYI FPV app kept saying that there is a software mismatch so I found out I did not actually upgrade the camera firmware, because of the microSD card that I used for the upgrade. After upgrading to v0.2.7 I am not able to see any video in the SIYI FPV app, though I can on Siyi version of QGC that is running on the Herelink.
Here’s a screenshot of a wireshark capture. All UDP datagrams contain exactly one SIYI packet, except this one that has two: 0x0E followed by 0x0F. Is there special meaning to putting two packets in the same datagram? If there isn’t, I would encourage you to make an explicit rule one DG/one packet and simplify our lives.
Thank you for this clarification. I read it about 10 times, and I think I understand your meaning. Let me see if I have this right:
“For every request packet, the camera responds with a single packet, and the response CMD_ID is the same as the CMD_ID in request packet. This rule has two exceptions: 1: CMD_ID
0x0Cwhich returns no response; 2: CMD_ID0x0F, which returns two responses:0x0Ffollowed immediately by0x05.”
If my understanding is correct, I take back what I said about asynchronous interfaces. The interface is still completely synchronous (yay!) but has a special case for 0x0F. If this is correct, may I suggest changing the return data format for 0x0F to be exactly like 0x05, and remove the special case where 0x0F returns two packets.
I’ve been looking ant more Wireshark traces and fiddling with different parameters. When I send fewer packets to the camera, I see many more 0x05 packets from the camera. I have a new potential understanding of the protocol:
“Some packets to the camera elicit immediate responses with the same CMD_ID as the request, e.g., if you send an ACQUIRE_HARDWARE_ID request, the camera immediately sends an ACQUIRE_HARDWARE_ID response, and this completes the transaction. Other packets command long-running tasks and result in periodic, unsolicited packets from the camera which update you on the progress the camera is making in fulfilling your request. For example, sending an ABSOLUTE_ZOOM command elicits an immediate ABSOLUTE_ZOOM response, followed (every 20 to 50 milliseconds) by a MANUAL_ZOOM packet that reports the current value of the zoom. Camera continues to send these MANUAL_ZOOM packets, interleaved with other communication as necessary, until zoom reaches the value you specified in the ABSOLUTE_ZOOM packet, or until another packet from yo supersedes this request.”
Is this closer to truth?
Can i use siyi camera with power distribution board?
And, On your first post Working Voltage: 11 ~ 25.2V, so is it okey to use 6S lipo battery?
Separate power is better
6S is not safe. The range is 3S to 4S (11 ~ 16.7V). Please refer to the latest manual.
@SIYI Is it possible to get older versions of the ZR10 Camera, Gimbal and Zoom firmware. Google drive contains only Camera 0.2.7, Gimbal 0.2.4 and Zoom 0.2.0.
On the latest version gimbal stabilization differs from the old one. Or is it possible to reset to the factory defaults.
Thank You in advance.
What is the difference that you encountered?
@SIYI When gimbal catches max roll angle it returns to the start position. If at the same moment uav returns into horizontal state (or rolls another direction) gimbal appears not horizontal. Sometimes it takes up to 10-15 seconds to stabilize gimbal, which is too long for us.
Older firmware had faster stabilization speed, which was better for us.
Thank You for understanding.
Frank, what is the range of focus for ZR10? I see the manual says minimal distance is 200mm. What is the focus distance at infinity?
Ari.
Hi Frank,
I tried upgrading the gimbal firmware and it got successfully completed as well. However, on the next boot the camera led started blinking red and it does not connect to Siyi Assistant software as well. What shall I do now?
