|
|
Post by ukyeclipse on Mar 10, 2017 11:59:54 GMT -7
The title may not be the best description of our error but here is what we are having issues with:  To our understanding the code is running appropriately, the ground station however is not catching any of the picture bytes. The picture above shows what we are seeing. Everything connects like its supposed to (we connect and catch packets). When we ask for a picture, the package and ground station do communicate. The problem occurs when the code is trying to receive the first actual packet of the picture. That is when we get what is above. The code does save a picture file (which is blank). This leads us to believe the code is running appropriately. We did just update the firmware on the RFDs so that we could get 3 RFDs to communicate at the same time. Maybe this has something to do with this? Is there something that may need to be altered in the Pi code that we are unaware of? |
|
|
|
Post by deniseund on Mar 10, 2017 15:28:35 GMT -7
We are having a similar issue- here's a screenshot of the code in anaconda. Our GUI eventually stopped responding and we couldn't disconnect the pi in putty (timeout error) so we did a force shutdown of the payload. After turning it back on again and reconnecting to the ground station, it seems to be working. Maybe try shutting it off and on and see if it works- it didn't corrupt our SD card and we did it several times. UPDATE: our systems are working intermittently. We're bouncing between the original issue, working as normal, and in some cases the laptop will download the image but it will not display on the GUI and is showing as a blank image file in the RFD Ground Station folder (here the image file is being automatically saved as a .png file, whereas the good images are .jpg). The putty still will not connect to the pi. Attachments:
|
|
|
|
Post by Wesley on Mar 12, 2017 18:55:05 GMT -7
The title may not be the best description of our error but here is what we are having issues with: To our understanding the code is running appropriately, the ground station however is not catching any of the picture bytes. The picture above shows what we are seeing. Everything connects like its supposed to (we connect and catch packets). When we ask for a picture, the package and ground station do communicate. The problem occurs when the code is trying to receive the first actual packet of the picture. That is when we get what is above. The code does save a picture file (which is blank). This leads us to believe the code is running appropriately. We did just update the firmware on the RFDs so that we could get 3 RFDs to communicate at the same time. Maybe this has something to do with this? Is there something that may need to be altered in the Pi code that we are unaware of? Was this test conducted with all three units running or was is just with just the payload and one ground station? As far as needing to upgrade any software, no changes are needed. What settings are you using on your RFDs? After the workshop, we found that when requesting pictures we would get a filename with a .png extension (expecting .jpg). We ended up experimenting with different settings before we could consistently receive pictures. What settings are you running? |
|
|
|
Post by ukyeclipse on Mar 15, 2017 7:22:57 GMT -7
We tried the TX power and no luck, still the same error. We have had these working before updating them to do the multipoint. Also for now we are only trying to get one ground station to connect to one payload (using the updated RFDs). We are testing multiple settings at the moment to see if anything helps.
Also as a note, the RFD on the package when turned on does not flash anymore (this has happened since the update). No other RFDs are on so we are under the impression it should be flashing?
|
|
|
|
Post by ukyeclipse on Mar 15, 2017 14:12:17 GMT -7
So we have had some success on this problem today. We found that by changing "Node Count" to 2 instead 3 (which we had been using). Now all 3 RFDs connect and the 2 ground stations do begin to download parts of the pictures. Below is a picture that shows what is happening. We have gotten up to about 130000 before the error. Just as a note when we connect just one of the ground stations and the payload the pictures download just fine. Its when we turn on and connect all three that we still get the interruption. We have the powers turned down and ground stations are 20ish feet and the payload is around 50 feet away from them.  |
|
|
|
Post by Wesley on Mar 16, 2017 9:39:13 GMT -7
Ok, the RFD image software doesn't handle flushing the serial buffer between the RFD and the computer (if there is one) except when it syncs which can cause all sorts of weird behavior when using two or more ground stations. Basically, whatever the payload sends, it is sending to both ground stations. This means that which ever ground station didn't request the picture is the one that is going to have a buffer full of unexpected data. I'll use the settings above and test this out but for now, try the settings above and power all three modems but only have one GS running the software and the payload running. Just leave the other ground station RFD powered with nothing running on it to see if you can transmit pictures from the payload to GS #1 with three nodes on the network (GS #2 not doing anything). I will report back what we find on this side but I'm confident we can find a solution for this.
|
|
|
|
Post by deniseund on Mar 21, 2017 12:17:47 GMT -7
How do we find the RFD settings? We are once again getting the error mentioned in the original post. The program continues to work normally, then it will mess up, then work normally... not sure why as we are not changing any settings.
|
|
|
|
Post by ukyeclipse on Mar 21, 2017 14:41:36 GMT -7
I believe what your looking for is here: eclipse.montana.edu/workshop-resources/"RFD Configuration Videos" (its near the bottom of that list) and it walks you through how to access the settings. I don't believe that you'll actually have to configure the RFDs, but these videos show how to access the settings. |
|
|
|
Post by David MSGC on Apr 2, 2017 11:42:25 GMT -7
The 'defualt' settings are in a screenshot in the RFD_Resources folder on the GS laptop. I don't think any of your errors are from RFD settings. Usually if it is in the RFD radio settings you would not get a connection at all or would not recieve the first packet. Some of it looks like you might have duplicate image names in the same file. If the battery died on the real time clock the folder name will not change and you are duplicating image names in the same folder. I would check to see if it is creating a new folder with the current time stamp each time you start the RFD program. Another thing I have seen create similar errors is the pi has ssh over serial enabled. This will add encryption data to each packet sent over serial and the RFD program will not work with the 'extra' data in the packet. In raspi-config there is a setting that you can turn off ssh over serial. These were turned off on the original OS image and if you never messed with it is should be fine. Make sure also that there is no other program on the ground station that is trying to access the same com port as the RFD FTDI cable, this will 'add' extra data to the serial buffer and give similar out put as you are seeing. The first couple screenshots with the goofy file name is when the radios are not connected it should be in the format of image00x.jpg/png and not lakjjslkj948.jpg
|
|
|
|
Post by David MSGC on Apr 3, 2017 11:48:01 GMT -7
The only time I could recreate this error is by enabling ssh over serial in raspi-config or when the radios where power cycled or not paired(blinking green led, even if it blinks once in 30 seconds they are not paired) Not guaranteeing this is your exact problem but a very good place to start. The only time I ran into this myself is when both ssh was enable over serial and when the green light would flash so I cannot say which one was the cause when I had it. (this was when we first switched from the old to new radios, also the same time we ran into the flashing green led)
If ssh over serial was not enabled then I would power cycle the ground radio by unplugging and re-connection the ftdi cable at the radio and not the computer. Uplugging at the radio will not require a restart of the rfd python program where unplugging at the computer will crash the program and require a restart. If this still does not solve the issue you can verify the radios are paired by going to the 3dr program in the rfd900-resources folder on the desktop and run the signal strength test, rssi tab. If the radios are not paired you will see zero for a remote radio signal strength or the signal strength for the remote radio will appear as a square wave in the plot. If the radios are paired the remote radio signal strength will be higher and a fairly steady line and not a square wave. When doing the signal test you will have to close the rfd python program so not more than one program is trying to access the same com port. Reminder: all the systems that use a com port can only have one program accessing the same com port at a time.
|
|
|
|
Post by deniseund on Apr 21, 2017 15:17:16 GMT -7
We tried running the program today, and it did capture images the first time it was launched. After disconnecting and re- connecting, the lights were flashing and we were receiving the empty files. We then checked Raspberry Pi settings, and it looks like ssh was enabled over serial, so we changed it. The program now doesn't work at all (it freezes and will not respond at all as soon as we click "view most recent image"). When we try to connect to the putty to safely disconnect, we are no longer able to, because the working settings that were pre- loaded had SSH checked, not serial. The putty does not recognize the settings now that ssh is disabled. When we click "serial" instead, it still does not recognize the pi, even when we enter the correct port number and baud rate. The lights on the RFDs are not flashing (although they were before we changed ssh to serial). We tried power cycling the ground radio, but that did not work. We opened the 3 dr program and attempted to run the signal strength test, but after going to the RSSI tab and entering the correct port and baud settings, we get a popup that says "Bad Port Setting." We did have to install a new RFD900 modem on the ground station a few months ago, because a pin on our original one snapped. Could this have anything to do with it?
We also noticed earlier this week that when the program was working, the images came in labeled with a date 2 days in the future. The laptop had the correct time and date, but when we went into the terminal to look at the Raspberry Pi settings, the date was set to 2 days in the future. We have never had this issue before, and photos we received prior to Tuesday had the correct date and time. We did not change the date back to the present yet, and when the images were working a few hours ago, they still had the future date listed.
|
|
|
|
Post by David MSGC on Apr 21, 2017 16:57:02 GMT -7
When you ssh to the pi on the still image payload it is over wifi adhoc and not serial. The profile in putty for ssh is for the adhoc connection and not RFD. Changing ssh and serial settings in putty will not change anything with the leds on the RFD, the leds on RFD is between the two radios and not with the serial connection.
You need to get the leds to stop blinking before you start the python program on the laptop, if you already have the program started and you notice the leds blink you need to close the program and get the radios connected, no blinking led, first.
First turn on the pi, make sure the camera led lights telling you the program is running, plug the ground side radio to the computer, watch the LED on the RFD radio, if 30 seconds go by without the LED blinking then start the program on the laptop. If the LED blinks at all, power cycle the ground side radio until it no longer blinks, then start the program on the computer. If the blinking light does not go away the settings on the radios may not be correct. The port settings and serial settings on the laptop should not be changed. Putty is not used with RFD, only wifi(on the still image payload, video payload is different)
|
|
|
|
Post by David MSGC on Apr 21, 2017 17:04:41 GMT -7
 I just noticed earlier posts had the wrong settings posted for the RFD settings, the correct settings are shown in a screenshot in the RFD_resources folder on the desktop of the ground station laptop. |
|
|
|
Post by David MSGC on Apr 21, 2017 17:09:53 GMT -7
Settings used where the following (sorry no picture, using a different computer): Baud: 38400 ................................................Min Freq: 916000 Air Speed: 48 ...............................................Max Freq: 928000 Net ID: 2 .....................................................Num of Channels: 50 TX Power: 20 ................................................Duty Cycle: 100 Node ID: 0 for the payload, 1 for the GS ..........Node Count: 3 Node Destination: 65535 ................................Sync Any: unchecked ECC: Unchecked.............................................Op Resend: Checked Mavlink: Unchecked............................................RTSCTS: Unchecked This original post showed Mavlink being checked, it needs to be UNCHECKED |
|
|
|
Post by usc on Apr 21, 2017 18:47:16 GMT -7
Is it possible to change the "Node ID"? The settings to change Node ID are grayed out and set at 2 for both our ground station and payload. Could this be a possible error source? (RFDs communicate, SSH over serial disabled, payload signal in 3DRRadio is not a square wave, etc.) This thread is relating to our "GUI Connection Error" thread for RFD900 image transmission.  |
|
