|
Post by kendra on Jun 18, 2017 15:29:07 GMT -7
I tried restarting the tracker and it is pointing exactly opposite the payloads. We had this happen before occasionally. I have no idea why. Kendra Payload too close to antenna or IMU mounted backwards. The side of the IMU where the cable attache should be pointing the same direction as the antenna. The cable is pointing the same direction as the Yagi antenna and the sensor board is opposite it, right? That's the way I have it.
|
|
|
Post by kendra on Jun 18, 2017 15:29:48 GMT -7
Data is updating on the BOREALIS site every 30 seconds, but it is not updating in the GUI.
|
|
|
Post by kendra on Jun 18, 2017 15:47:23 GMT -7
Restarted the tracker and it is now pointed the right direction. I didn't do anything different.
It is still not updating the tracker graphs.
I'll let it sit for a while.
|
|
|
Post by kendra on Jun 18, 2017 15:56:02 GMT -7
It still isn't updating. I moved the Iridium modem to a different (far away) location and it hasn't updated.
Any ideas why it is locking up?
Kendra
|
|
|
Post by USC team on Jun 18, 2017 15:57:21 GMT -7
Hi,
We seem to be having the same problem. - The Iridium Data is showing up on the GUI and matches the data from the BOREALIS Website -The Iridium is more than 50 feet away from the ground station - The calibration for IMU is working properly and the bearing position is also pointed in the correct position - The cable to the IMU is pointed in the same direction as the Yagi antenna.
However when we hit "point to last balloon location" the bearing position is correct but the elevation angle says 180 degrees and is moving the tilt servo directly up. We've repositioned the IMU in every configuration, as well as repositioned the ground station and still the same result. We've also done this with "local Arduino", "south facing", and "north facing" on the GUI.
|
|
|
Post by kendra on Jun 18, 2017 16:07:30 GMT -7
10/12 times restarting, and it points opposite after the calibration.
Mine is saying Elevation Position for the Ground Station Date is 180.010263082. I have been using the Local Arduino as well.
Kendra
|
|
|
Post by kendra on Jun 18, 2017 16:08:56 GMT -7
USC team, are you getting any data updating on your Tracker graphs?
Kendra
|
|
|
Post by kendra on Jun 18, 2017 21:17:52 GMT -7
I just looked at the new calibration instructions. I have been using the old method of calibrating. Doing the figure "8" for mag. Laying it flat and then doing the 3 different axes (including on its end) rather than only turning it on its single axis parallel to the ground to get the acc. calibration. Maybe turning it on the last axis is making it think it is pointed the opposite way. I'll test it in the morning.
I did get the tracker graphs to work once today, at the beginning, when the antenna was pointed straight up. Again, maybe the calibration process was to blame being 90 degrees off rather than 180.
Kendra
|
|
|
Post by Austin MnSGC on Jun 19, 2017 6:03:17 GMT -7
The tracker graphs start updating when you launch the antenna tracker. It will update every time a new balloon location is received and it is newer than the previously received location. You can see the current balloon location in the Incoming GPS table on the top left. This should be updating every time you get a new location.
In the Incoming GPS table, you can also see the bearing and elevation angles between that location and your ground station. That bearing and elevation angle should match the ones in the Ground Station Data table if you've launched the antenna tracker.
If you think it is pointing incorrectly, but the information in the side tables is correct, the problem is most likely that your GPS location/center bearing for the ground station is off.
|
|
|
Post by kendra on Jun 19, 2017 8:41:06 GMT -7
It is working now.
I filled out our IMEI number the first time, but I thought it automatically filled our number after that. The default IMEI number is very close to ours. It turns out that the base station was trying to point north toward Minnesota which just so happened to be opposite our payloads toward the south. Their Iridium was not on so the graphs were not populating.
Kendra
|
|
|
Post by David MSGC on Jun 19, 2017 9:42:40 GMT -7
Things YOU NEED to LOOK AT. They will help you / us diagnose your problem. 1) Launch the application from a Anaconda or Command prompt (or batch file). After the UI launches, go back to the command window and check to see if there any errors listed. 2) Compare the GPS coordinates reported on eclipse.rci.montana.edu to the ones reported in the Incoming GPS Data window on the UI. 3) Look at the Ground Station Data on the UI and make sure it matches your Ground Station location and IS NOT changing. If either of the GPS locations are moving around, you may have ground affect / reflections that are interfering with your GPS. If your Ground Station Data is moving around, try going out of "Get Local" and type it in manually. Steps 1 and 2 are good practice, Step 3 is FALSE. The variation in GPS location is built in the firmware of all GPS modules and is to be expected, this is to make it more difficult to use a GPS module for guided weapons. Depending on the manufacture date of any GPS module the variation will be determined by what the law/rule was at that time. Up until a few years ago this variation was 9 meters. The Iridium GPS is in airplane mode and will have more variation than when in ground mode,(ground mode will not work above a certain altitude so we need airplane mode) the ground station antenna can also have a variation of 9 meters. This is why we suggest the Iridium is at least 50 feet in front of the antenna so the variation won't make the antenna pan servo move more than 180 degrees trying to point backwards. Before selecting "Launch Antenna Tracker" it is good habit to check the incoming data and desired bearing so that it makes sense and won't try to point backwards.
|
|
|
Post by David MSGC on Jun 19, 2017 9:49:00 GMT -7
It is working now. I filled out our IMEI number the first time, but I thought it automatically filled our number after that. The default IMEI number is very close to ours. It turns out that the base station was trying to point north toward Minnesota which just so happened to be opposite our payloads toward the south. Their Iridium was not on so the graphs were not populating. Kendra If the Iridium is not on there will be no data for the antenna tracker to go by, it will grab your last location that the modem was at the last time it was on. The antenna gets the balloon location data from Iridium data. It also helps to look at the Iridium data coming in on the website so that if the antenna stops updating you can tell if it is the Iridium not having a connection or something else.
|
|
|
Post by Austin MnSGC on Jun 19, 2017 11:29:53 GMT -7
It is working now. I filled out our IMEI number the first time, but I thought it automatically filled our number after that. The default IMEI number is very close to ours. It turns out that the base station was trying to point north toward Minnesota which just so happened to be opposite our payloads toward the south. Their Iridium was not on so the graphs were not populating. Kendra If you'd like your system to default to your IMEI, you can go into the ui_trackermain.py file, and edit line 1892. This establishes the placeholder text (default value) for the IMEI input. Change the value that's there (300234064909640) to your IMEI, and it should change the placeholder.
|
|
|
Post by kendra on Jun 19, 2017 11:31:51 GMT -7
We had the tracking disable a couple of times during the bench test today (6/19) because it couldn't access the Iridium server and we had to restart the program. Luckily, we were able to do it pretty quickly and get our stream going again. Do you think that was because of the stress on the server? Our internet connection was solid.
We are only using the Iridium for this test. We will try to update the RFD for the flight tomorrow.
Kendra
|
|
|
Post by David MSGC on Jun 19, 2017 11:55:17 GMT -7
We had the tracking disable a couple of times during the bench test today (6/19) because it couldn't access the Iridium server and we had to restart the program. Luckily, we were able to do it pretty quickly and get our stream going again. Do you think that was because of the stress on the server? Our internet connection was solid. We are only using the Iridium for this test. We will try to update the RFD for the flight tomorrow. Kendra What indicated it could not access the server? Did you get a 4xx error code? I would like to find out if it was the server or not. We have had only one report of not accessing the server and it was getting slightly over 1000 requests per minute.
|
|