|
|
Post by lenegene on Jul 20, 2017 15:40:37 GMT -7
Issue:
While trying to use RFD tracking, no GPS data is coming into the GUI.
Payload setup:
We have an Adafruit Ultimate GPS plugged into our still image Pi via USB. Our RFD modem is connected via FTDI->USB into the pi (however, we are powering the modem thru the pi, not USB).
Communication Status:
We have GPS lock and the solid green light is on our 2 modems saying they are communicating.
Software Versions:
We have flashed the June2017 Image onto our SD card, and we are using the latest Antenna_Tracker from MSU's GitHub (updated on June 12th). We have confirmed that line 11 in the file GetData.py does say 'import time' (that has been an issue for some folks).
Questions:
1.) Is there anything we are supposed to edit into the new code to initiate RFD tracking?
2.) In order to track with RFD, must we have both the Iridium and RFD boxes checked in the GUI? Or can the RFD run on its own?
3.) Do we need to have the still image camera plugged into the Pi in order for RFD tracking to work? (Because we currently aren't using it)
4.) Can anyone think of another reason why GPS is not being updated in the GUI?
Thank you so much for your help!
|
|
|
|
Post by Austin MnSGC on Jul 21, 2017 6:29:52 GMT -7
I can help with some of your questions.
1. I don't know about the different versions of the software out there, but the latest version of the Antenna_Tracker is what you should be using.
2. You can track with just the RFD, no Iridium is needed.
3. You don't need a still image camera, assuming you're using the version of the software that I'm familiar with. Again, I'm not familiar with what software is on the June2017 image.
4. What I would recommend is testing your payload independently. If you can, connect a monitor, keyboard, and mouse, and try to run the software directly. This will give you access to the output, and give you a better impression of why it's not working. It can be difficult to determine that the software is actually running on the pi, especially without the cues from the camera. If you can confirm that everything is working as it should be on the payload side, that limits where things could be going wrong to the ground station or radios.
I assume that you meant your RFD modem is connected to power from the power board, not directly from the Pi?
|
|
|
|
Post by lenegene on Jul 31, 2017 16:05:23 GMT -7
Thank you for your response.
Yes, I meant that our modem is being powered by the board, not the pi directly.
We connected our camera so that we could verify our modems are talking. We can receive a picture, so we think the issue could have to do with the GPS itself. When we click 'Request Status' on the RFD tab of the GUI, it says 'GPS: True', but still no GPS info populates the top left tab. Is there a way to have the GUI print the GPS queue?
Has anyone successfully used RFD tracking, besides Minnesota? If so, were there any specific changes you had to make to the code to fit your system? I say this because after connecting my pi to a keyboard and monitor, we discovered that the VID and PID for our RFD USB connection was different from MN's. Are there other changes we need to account for? I also noticed that the 'gpslog.txt' file that is created each time I run the program is empty if that is helpful.
Thank you!
|
|
|
|
Post by Austin MnSGC on Aug 1, 2017 6:47:59 GMT -7
If the GPS log is empty, then it's likely that you're not getting any GPS info on the payload. You can make edits to the GPSThread on the payload software to print anything you want, for example you could print what it's adding to the queue. If you can receive a status update or a picture, your radios are fine.
If the GPS doesn't have a fix, it will output all 0's, and the Ground station program will ignore those. However, they should still be added to the GPS log file on the payload. I would confirm that your GPS is outputting correctly.
|
|
|
|
Post by lenegene on Aug 2, 2017 9:50:05 GMT -7
We were looking through the python code on the still image pi, and noticed that there isn't really a command to initiate the GPS to start logging (from what we could tell). We are using an Adafruit Ultimate GPS, and we found out it is not a plug and play - it needs to be 'woke up'.
We hooked up an Arduino to our GPS module while it was plugged into the pi and ran an example echo code from the Adafruit GPS Library to make it start logging. Finally, GPS info is coming into the GUI, but only after this jump start with an Arduino.
Ideally, we don't want to have to do this on eclipse day. From what we can think of, there are three options:
1.) Jump start with Arduino on eclipse day (not desired)
2.) Jump start with Arduino, then insert a coin cell battery and never turn it off (so we can jump start the night before - still not desired because we don't know how those batteries react at altitude)
3.) Put a command in the python code to do what the Arduino is doing.
Is there something else that you guys are doing in Minnesota? Are we not using the most updated code? Because it doesn't seem like you have to go through this process with the GPS.
Thanks!
|
|
|
|
Post by Trevor MSGC on Aug 2, 2017 10:14:15 GMT -7
|
|
|
|
Post by lenegene on Aug 2, 2017 13:18:00 GMT -7
|
|
|
|
Post by Austin MnSGC on Aug 3, 2017 6:43:50 GMT -7
We use the same Adafruit GPS breakout, and do not need to wake it up. It begins outputting NMEA information when powered on, regardless of fix. How do you have it connected to the raspberry pi?
|
|
|
|
Post by Trevor MSGC on Aug 3, 2017 15:13:29 GMT -7
|
|
|
|
Post by Ryan MnSGC on Aug 4, 2017 9:28:15 GMT -7
While this is true, and Adafruit admits that they do not guarantee their modules for high altitude use, they also state that they have had users successfully implement their modules in high altitude applications on their FAQ. We've had mixed results in the past, but we've found that most modules tend to be consistent - if they work well on one flight, they should work again in the future. If you have more than one, try testing all of them on a flight before eclipse day to see which works best. However, this sounds like a different issue entirely, as you're not even getting data on the ground. I'd agree, with Austin, that sounds like a connection issue to me. |
|
