Hello,
I would like to be able to see/read the raw data transfer occurring at each of the individual UART ports for my Pixhawk without any pre/post processing by ardupilot. Is there a way to do this?
BR,
Arth
I dont think raw data can be logged or forwarded without first being processed into some relevant form. I suspect you would need a companion computer to log that data.
There is SERIAL_PASS1 and SERIAL_PASS2 to forward data between two ports, and the related timeout parameter.
https://ardupilot.org/copter/docs/parameters.html#serial-pass1-serial-passthru-first-port
If you give more details you might find someone has already done what you want.
Noted thank you for your answer.
Here’s what I’m trying to do: I have 2 GPS modules connected to my Pixhawk (on two separate serial ports of course), but at the moment I have no idea if both of them are working and communicating well with the FC or if only one of them is working, which one? My mission planner constantly just shows “No GPS” on the HUD screen despite there being a correct map location on the map screen and despite me being able to use all GPS modes (Loiter, RTL, etc.). My primary goal is to understand two things:
- Why does mission planner show “No GPS”.
- If only one of my GPS is working (logs only show GPS 0) then which one.
I’ve attached the last bin and log files for reference (too big, attached using gdrive).
OK, that’s a problem we can deal with and no need for special logging we dont already have available. I’ll check it out.
.bin log file access!
There is only one GPS found and it seems to be working OK.
This will be a problem:
GPS_TYPE2,0
It would need to be GPS_TYPE2,1
And this:
SERIAL4_BAUD,9
will probably need to be SERIAL4_BAUD,230
Usually the GPS can still be found and reconfigured to work properly even with that high baud rate.
What model is your second GPS?
This will be a problem:
GPS_TYPE2,0
It would need to beGPS_TYPE2,1
Ah I forgot to set the second GPS to auto config. Will try thank you!
SERIAL4_BAUD,9
will probably need to beSERIAL4_BAUD,230
Usually the GPS can still be found and reconfigured to work properly even with that high baud rate.
Out of curiosity, do I not need to match the baud rate of the GPS? Because I know that one of my GPS operates at 9600 bps (verified with ublox ucenter).
What model is your second GPS?
Both of them are Neo M8Ns but one of them I just bought and the other one is a bit old (this one has the internal baud rate set to 9600 bps) pulled out from an older vehicle.
BR,
Arth
Try different baud rates until it works, start with the higher value first. Reboot the FC each time.
I’ve also got at least one old GPS unit kicking around somewhere, were I cant seem to change the baud rate or save any other changes.
u-Blox GPS modules are auto detected at any valid baud rate, and the auto configure routine will change it anyway.
@xfacta @Yuri_Rage Thank you both, " GPS_TYPE2" and “SERIAL4_BAUD,230” allowed the GPS to automatically get detected and now I can see both my GPSs in the logs. 
1 Like
Sorry I completely forgot about my first problem. My mission planner still is stuck on “No GPS” but as I mentioned just cosmetically as I can freely use all GPS enabled functions. Any idea what I could do to troubleshoot this problem?
BR,
Arth
Usually this error would be caused by an expected GPS is not found.
Let’s see what’s going on in the background.
Set LOG_DISARMED,1 and reboot.
Allow the copter to sit connected to MissionPlanner until the errors go away (if they do) then set LOG_DISARMED,0
Reboot and grab the .bin log that was created.
Upload it to dropbox or somewhere similar and send the link to it.
Alright, I set LOG_DISARMED,1 and let the copter sit connected to MP. Here is the link to the .bin file.
Also now, apparently I cannot arm the copter. I constantly get bombarded with “GPS2: Still configuring this GPS”. Which is very strange because last week I remember very well being able to arm with both my GPSs connected and then both the GPSs appearing also on the logs. ://
It looks like GPS2 eventually starts responding OK of a fashion, since it begins providing a good HDOP and the same latitude and longitude as GPS1.
I think you could put this in place:
SERIAL4_BAUD,230
The GPS driver routine starts trying all valid baud rates if a unit fails to respond properly at 230k baud.
To be completely correct, you’d be able to see in messages something like:
GPS 2: detected as u-blox at 230400 baud
and then you could set that baud rate in Serial4
Set these too and try again:
GPS_GNSS_MODE,65
GPS_GNSS_MODE2,65
This limits the number of constellations so the GPS units are not overwhelmed. This might make it easier for the GPS units to work. Later when everything is working OK you can mess around with the selections to get the lowest and most reliable HDOP in your area.
You just pick 2 of them except SBAS or IMES. Usually only choose GPS, Galileo or GLONASS.
SERIAL4_BAUD,230 - Done
GPS_GNSS_MODE,65 - Done
GPS_GNSS_MODE2,65 - Done
GPS 2: detected as u-blox at 230400 baud - This does show up in the messages. See image below:
I left the vehicle out in the open for about 10 mins (log attached here), but the last few messages about GPS2 in the image just keep repeating. I cannot arm with the Pre-Arm message: “GPS2: Still configuring this GPS”.
And further, my mission planner keeps showing “GPS: No GPS”. 
I feel like giving up on the idea of using 2 GPSs. But I’m so annoyed that my mission planner does not detect the GPS. Any more ideas to try?
BR,
Arth
MissionPlanner is just the messenger 
There is quite a bit that goes into checking the GPS units and getting them configured in Ardupilot, so it may be that GPS2 really is faulty, or at some stage someone made permanent changes to it for a specific reason.
You can connect it up to U-Center and see what’s strange about it, but that’s probably not worth the effort these days, with such small cheap GPS units readily available.
And apart from that any relatively new GPS unit is so much better than an old one, any interference that affects a new one will guarantee the old one is already long gone.
I’ve got an old GPS unit kicking around here somewhere, it must have been setup for electronic/robotic projects years ago. It wont work with Ardupilot (or nearly anything else) because config changes cant be saved, and most useful changes dont even take effect. It’s like they were a cut-down firmware just for simple project use.
Okay noted, I’m finally getting rid of the second GPS and will keep using the newer GPS 1. Thanks for all the help Shawn, much appreciated. ;))
I’m still a bit bothered about “GPS: No GPS” on mission planner. Can I debug that somehow or is that also a lost cause?
BR,
Arth
Set this:
GPS_TYPE2,0
It will stop Arducopter from trying to find a second GPS.
If you still have trouble we’ll need to know what your first GPS is and see the parameters - I was going to check that log from earlier but it’s gone now.
The file hosting site I used earlier was deleting my uploads every few hours, pretty annoying. I switched to another one. This link contains 2 log files. The 002 is the one when I had both GPSs connected and was trying to get it to work. The 004 file is from a successful flight using Loiter, RTL and Guided mode. For the 004 flight, I had GPS_TYPE2,0 and only my primary ublox M8N connected.
BR,
Arth
I see it takes some time to get GPS1 going, but it does come good.
Try this, see if it helps:
BRD_BOOT_DELAY,3000
and definitely set this:
BATT_FS_CRT_ACT,1
Set these to get your tuning adventure under way:
PSC_ACCZ_I,0.30
PSC_ACCZ_P,0.15
INS_HNTCH_ENABLE,1 <- set this the refresh to see the rest
INS_HNTCH_MODE,1
INS_HNTCH_REF,0.12
INS_HNTCH_FREQ,90
INS_HNTCH_BW,40
INS_HNTCH_FM_RAT,0.7
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4
There is some instability so you’ll have to do a flight to gather more date with the above settings, confirm the harmonic notch filter is working (or fix it) and move on to Autotune.
After the battery discussions on the other thread I’m moving to a smaller, lighter quad frame, EMAX motors and ESCs and a better battery. I will re-assemble the entire vehicle and start over. Hopefully I get better flight times and can tune the copter with the new setup. I will also try BRD_BOOT_DELAY,3000 to see if it helps the GPS problem. Thanks for your time Shawn.
BR,
Arth