|
|
Post by njordan on Mar 7, 2017 21:23:02 GMT -7
Hello, We had our first test flight this weekend and we had some serious problems. As soon, as the payload left the ground, the RFD would fail to transmit full pictures if at all, but the request would be received. The signal light was solid green the entire time. Also, Putty refused to communicate with the video at startup and RFD at shutdown, each time giving a timeout error. I'm stumped... every thing was working great a week ago.
|
|
|
|
Post by Wesley on Mar 8, 2017 23:34:24 GMT -7
When you say full pictures, did the still image payload start to transmit data and then eventually fail in the process? As for the video payload, you said it wouldn't communicate at start. Were you able to communicate once it was a certain distance away? What state were the signal strength indicators in on the Ubiquiti modems (full strength or weak to no signal)? How was your tracking system operating?
|
|
|
|
Post by njordan on Mar 22, 2017 17:32:39 GMT -7
Tracking system was fully functioning. we never did regain communication, and the system was at full strength. After recovery, the rfd refused to communicate through putty as well.
|
|
|
|
Post by David MSGC on Mar 29, 2017 9:39:07 GMT -7
How are you trying to use putty over rfd? Are you trying to send the command that the GUI sends? If you are trying to ssh over rfd it will not work, it is turned off in the raspi-config and this is need for the program on the pi to work, if ssh over serial is enabled the rfd program will not work, it sends a bunch of exttra data the rfd program does not recognize. If the ssh over serial is enabled you need to turn it off or it will not be able to send pictures. If you are talking about using putty through the adhoc it has a very short range, around 100' line of sight.
|
|
|
|
Post by David MSGC on Apr 3, 2017 11:38:00 GMT -7
Not being able to ssh over putty on either system could be from Windows Firewall blocking putty. If McAfee is controlling the firewall it will not block putty. Some windows updates will change which program controls the firewall. If an update made Windows Firewall now control the firewall you will have to create an exception for putty in Windows Firewall. Even if this is not the case for you not being able to connect over ssh with putty I would still add the exception so a future update does not block putty.
If RFD does not transmit the whole picture it is usually due to the radios not being paired, it will send a couple packets and error out. If it is poor signal it will retry 5 times and time out. If it errors out I would run the signal test that is in the 3dr radio utility in located in the rfd900_resources folder on the desktop of the GSLaptop. It will give you a signal strength of both radios, if the signal strength of the remote radio is at zero or looks like a square wave on the plot the radios are not paired, power cycle the ground radio by unplugging and re-connecting the ftdi cable at the radio, not at the computer usb plug. Unplugging from the radio will not require a restart of the RFD python program where unplugging from the computer will require a restart of the python program. When doing a signal test you will have to close the RFD program or you will have two programs trying to access the same com port, which will give you errors. On all the systems that use a com port be sure only one program at a time is using the same com port.
|
|
