Hi All,
I saw a thread on the camera working correctly for longer after a power cycle and a mention by Kevin Watson that you might have to hold the reset switch on the RC? for 5 seconds but I can’t seem to find those posts. Anyway, we are having the same problem. Last night, I captured the binary data from the RC to the CAMERA and from the camera to the RC and what I found was that a zero byte is inserted into the data stream from the RC to the camera every now and then. The camera NCK’s and our code which was not expecting that times out on the ack and tries to re-initialize the camera which will struggle to get acks from the CR packets and finally get T packets coming again for about a second. We are putting the camera in polled mode [PM11] so that we can correlate the virtual window settings with the next T-packet returned from the camera.
Anyway, the attached file shows a binary dump of the traffic from the RC to the camera in a state where there is no target so no VW commands are sent, only TC packets each time the camera ACKs.
Notice that byte 885 and byte 1358 are inserted 0’s. I was hoping that the delta would be some function of the serial port buffer size but 473 in this case is pretty strange. I guess I will collect more data tonigh - our second Fix-It-Window this week and see if I can find a correlation. The binary file was collected using TeraTerm. Any suggestions would be appreciated. Obviously I will be looking at the serial port driver and interrupt code. Oh, this is KW’s 10-Jan-2006 serial code, I think the latest.
RC_TO_CAM.txt (13.1 KB)
RC_TO_CAM.txt (13.1 KB)
I forgot to mention that a short reset was executed at byte 664 - you can see that the system goes through its normal initialization sequence and gets tracking packets until the zero inserted at 885.
Greg
Are you using the default camera code?
The code I am using is Kevin Watson’s 2007 streamlined code with modifications to send virtual window commands when the confidence is in the range for two target detection. The code will usually work for 15 minutes or more if I start it by disconnecting the main battery and wait until the backup battery operation stops. But eventually communication between the RC and the camera degrades and the extra zero bytes shown before happen. Because they happen in the middle of the tracking packet (in the example I posted) and I am using Kevin’s code to send a properly formatted tracking packet there is something else going on in the system that is dependent on start-up conditions. It is possible that some residual IFI serial port code is writing to the serial port transmit register from time to time so I removed all of the code I could that might do that except for what is in IFI’s library. I am stumped as to where the zero bytes are coming from and I am convinced they are real because the camera NCK’s the packets with the zero bytes.
How are you sending your virtual window command?
It should look something like
send_byte(‘v’)
send_byte(‘w’)
send_byte(4)
send_byte(x1)
send_byte(y1)
send_byte(x2)
send_byte(y2)
thats not the function… i think the right function is Write_Serial_Port_Two()… anyway how are you formatting your virtual window command?
Max,
We are using KW’s virtual_window() routine. For the data I included in the first post the code was not sending any VW commands because there were no targets in view. The code segment that cycles through the windows is below. This code is inserted after a T-packet is received. Right now CAMERA_POLL (the camera is in polled mode) is defined and CAMERA_NORMAL is not. The pending flags are used so that subsequent ACKs from the camera trigger the transmission of Tracking packet command after the VW command is acked and also to try to re-send the VW command if it is NCK’d. If the camera does not respond for 1000ms the KickCamera() routine runs which tries to recover the serial link (with limited success). The camera is working great and we have very accurate angles to both targets until the RC transmit serial port hickups - that is where we need the help, with the serial port. Are you looking for more information on how to use the VW command or did you think that we might be having trouble with its format?
Thanks,
Greg
if((((T_Packet_Data.confidence > CONFIDENCE_THRESHOLD_DEFAULT)&&(T_Packet_Data.confidence < TWO_TARGET_CONFIDENCE_THRESHOLD))&&camera_window == W_FULL)|| camera_window != W_FULL )// Two targets are in view or they were the last T-packet
{
if(camera_window == W_FULL) // Take a look at the left side
{
// camera_window = W_LEFT;
#ifndef CAMERA_NORMAL
mx_full = T_Packet_Data.mx;
Virtual_Window(T_Packet_Data.mx, 1, 159, 239); // LEFT HALF
vw_cmd_pending = 1;
DEBUG((“VW_LEFT\r”));
#endif
#ifdef CAMERA_POLL
t_packet_waiting_for_ack = 1;
camera_window = W_LEFT;
#else
expecting_window = W_LEFT;
#endif
DEBUG(("
Camera: Left Window
"));
}
else if(camera_window == W_LEFT) // Take a look at the right side
{
//camera_window = W_RIGHT;
#ifndef CAMERA_NORMAL
Virtual_Window(1, 1, mx_full/T_Packet_Data.mx/, 239); // RIGHT HALF
vw_cmd_pending = 1;
ScheduleEventTimer(KickCamera,1000,0);
DEBUG((“VW_RIGHT\r”));
#endif
#ifdef CAMERA_POLL
camera_window = W_RIGHT;
t_packet_waiting_for_ack = 1;
#else
expecting_window = W_RIGHT;
#endif
DEBUG(("
Camera: Right Window
“));
}
else if(camera_window == W_RIGHT) // Take a look at the full frame again
{
#ifndef CAMERA_NORMAL
Virtual_Window(1, 1, 159, 239); // FULL
vw_cmd_pending = 1;
ScheduleEventTimer(KickCamera,1000,0);
DEBUG((“VW_FULL\r”));
#endif
#ifdef CAMERA_POLL
camera_window = W_FULL;
t_packet_waiting_for_ack = 1;
#else
expecting_window = W_FULL;
#endif
DEBUG((”
Camera: Full Window
"));
}
}
else // One or no targets detected this time
I have collected more data on the camera’s reaction to inserted bytes and of course it depends on where they are inserted. In the attached dump a zero was inserted as the third byte of the Virtual Window and the camera actually ACK’d the command but was not happy subsequently.
What the attached file shows is the output from an RS-232 snooping program (wSHDCOM) that collected CAMERA (com1 real serial port) and RC (com4 USB adapter) data at the same time. Because of the PC serial port buffer timing it takes a little work to unravel the actual sequence of events…
In the packets in sequence section, the actual time offset from the previous packet is shown. As you can see, the camera normally acks a command almost immediately. One interesting thing is that after a TC command is received, the camera outputs an ACK and the FF immediately and then spends 63ms or so processing the T-Packet data. I expected that the FF would be connected to the T-Packet not the ack timing wise. Of course, the time it takes the RC to respond to Camera Ack or a T-Packet depends on how long until the next 26ms loop hits at least for us.
If our code does not hear from the camera in 1000ms we just set “camera_initialized” back to zero - which is not elegant but does the trick until the RC hickups again and transmits a random zero.
The good news, if there is any is that the RC does not transmit a random zero for a long time (typically 4) minutes after a power cycle. My worry is that the camera comms could take a hit before autonomous actually begins if there are delays in getting the field going.
I would really like to hear from anyone that has a theory as to why the serial port is inserting zeros - if we could fix that I would sleep much better!
Greg
Zero_Inserted_in_VW_COMMAND.pdf (23.1 KB)
Zero_Inserted_in_VW_COMMAND.pdf (23.1 KB)