On Fri, May 22, 2020 at 12:45 PM Gary E. Miller <
address@hidden> wrote:
> First; what am I trying to do? The long term target is to develop a
> tightly integrated kalman filter for attitude and location
> estimation.
Good luck with that, certainly the highway you the hard way.
We have an in-house developed loosely integrated kalman filter that we have been flying with for over a decade, but we would like to do a tightly integrated version. We aren't trying to reinvent the wheel or improve the state of the art in accuracy, but instead, having our own in-house system tightly integrated system would lay the groundwork for us to be able to do other more interesting higher research projects going forward. We are interested in exploring some different ideas of redundancy through software rather than replicating physical hardware. That is the theory anyway.
[curt said:] All the work we do in our lab is published under the MIT open-source license.
Where?
Here is our main Github repository for our lab. Many of our student projects are scattered all over and in their own personal repositories. For core lab work we are trying to become more organized as we go:
> By my understanding,
> this project will require knowing satellite orbital information,
> locations, etc., and (by my understanding) this requires reading and
> parsing subframe messages.
Require the orbital info? Yes. From subframe messages? No, many
sources for that info.
Without details no way to suggest options.
My understanding was that orbital parameters come from the subframe messages, and then the orbital parameters go into known equations to compute actual locations in ECEF? I know parts of the puzzle and am trying to get up to speed on other parts, and I'm sure there are things that have not even hit my radar screen yet. Are there better ways to do this?
For whatever it's worth, my roll in this is to support our student projects. So I am trying to plow through the difficult nuts and bolts of low level protocol decoding, communication, hardware connectivity, basic driver setup, etc. Otherwise you hand this to a student who's never seen a binary protocol before and they could struggle for a year just trying to get messages out of the gps.
Hopefully if I can work through all the tricky and fiddly (but not phd level) protocol and communication issues, then I can hand this off to a student to work on all their high level researchy stuff.
I stumbled on gpsd again today (I have used it a number of years ago but forgot about it when we moved towards plugging our gps's directly into arduino processors.) But for this upcoming work, doing everything on a desktop with gpsd would be great if that saves us some headaches on the low level.
Send here the output of this, so we can see what you have:
ubxtool --p STATUS -p CONFIG
See above, this isn't working for me?
But only first step in a long journey.
Yup, and probably even longer than that. :-)
You don't. Your gpsd is doing exactly what it needs to do as a daemon.
You effort will be as a client. Look at the gpsd clients, obviously
influenced by your programming language of choice.
Dumb question. So then is the subframe.c code being used by certain clients, not gpsd? I didn't look too closely at the build system.
> Is there a way to coax gpsd into parsing my
> subframes and extracting all the values for me?
As you say, it already does that.
I see that gpsd is parsing the basic ublox binary messages to get the raw subframe bytes, but what I want to do is extract the satellite orbital information from those raw bytes ... subframe.c seems like code to do this, but it sounds like gpsd doesn't invoke that code, and I need a client instead? I definitely do not fully understand the architecture/ecosystem of gpsd. I couldn't find any documentation on the subframe stuff within the gpsd ecosystem. Is there a client you can suggest for me to try? I'm happy with C or python, or do I need to be writing my own code and making libgps calls? At this point, if I can just get the subframe data decode and spit out those numbers, I'll be super happy. We have a student lined up for the summer to work on figuring out how to take this data and actually compute the satellite locations, and possibly start working on the tightly integrated kalman filter stuff. (And I know there will be a lot of housekeeping work in the middle to manage all the information.)
Easy way to start:
gpspipe -w
This works and gives me "TPV" messages (I'll assume you won't call in an airstrike with this information!)
{"class":"TPV","device":"/dev/ttyACM1","mode":3,"time":"2020-05-22T18:28:22.100Z","leapseconds":18,"ept":0.005,"lat":45.138033600,"lon":-93.157056700,"alt":280.885,"epx":9.219,"epy":9.337,"epv":4.122,"track":227.0438,"speed":0.108,"climb":0.002,"eps":0.04,"epc":0.01,"ecefx":-248209.58,"ecefy":-4500066.91,"ecefz":4498359.51,"ecefvx":0.02,"ecefvy":0.00,"ecefvz":0.02,"ecefpAcc":4.65,"ecefvAcc":0.60,"eph":2.162,"sep":31.350}
And then also the raw info (pseudorange, doppler, carrier phase) coming from the RXM-RAWX message:
{"class":"RAW","device":"/dev/ttyACM1","time":1590172120,"nsec":207999944,"rawdata":[{"gnssid":0,"svid":17,"snr":30,"obs":"L1C","lli":0,"locktime":64500,"pseudorange":22874715.973900,"doppler":-649.324463},{"gnssid":0,"svid":30,"snr":27,"obs":"L1C","lli":0,"locktime":64500,"pseudorange":25836850.828242,"doppler":-4446.262695},{"gnssid":3,"svid":25,"snr":27,"obs":"L2Q","lli":0,"locktime":16600,"pseudorange":26125344.408047,"doppler":-3661.114502},{"gnssid":3,"svid":11,"snr":37,"obs":"L2Q","lli":0,"locktime":64500,"pseudorange":24391699.188991,"carrierphase":127013968.937878,"doppler":-1938.677246},{"gnssid":6,"svid":11,"snr":21,"obs":"L1C","lli":2,"locktime":0,"freqid":7,"pseudorange":22639934.238152,"doppler":1889.118530},{"gnssid":6,"svid":21,"snr":31,"obs":"L1C","lli":0,"locktime":64500,"freqid":11,"pseudorange":22517210.880889,"carrierphase":120494124.878144,"doppler":1516.949463},{"gnssid":0,"svid":19,"snr":19,"obs":"L1C","lli":2,"locktime":0,"pseudorange":23213447.878444,"doppler":1043.709717},{"gnssid":0,"svid":13,"snr":13,"obs":"L1C","lli":2,"locktime":0,"pseudorange":27553456.406517,"doppler":-3727.632568},{"gnssid":0,"svid":28,"snr":30,"obs":"L1C","lli":0,"locktime":64500,"pseudorange":23033421.708142,"doppler":-1484.134521},{"gnssid":2,"svid":24,"snr":20,"obs":"L1C","lli":2,"locktime":0,"pseudorange":24457148.311457,"doppler":-2070.583008},{"gnssid":2,"svid":25,"snr":34,"obs":"L1C","lli":0,"locktime":64500,"pseudorange":26458933.035205,"carrierphase":139042628.813843,"doppler":674.808838},{"gnssid":2,"svid":12,"snr":28,"obs":"L1C","lli":0,"locktime":64500,"pseudorange":24520638.976233,"doppler":-1951.833984},{"gnssid":2,"svid":12,"snr":30,"obs":"L7Q","lli":0,"locktime":64500,"sigid":6,"pseudorange":24520633.132619,"doppler":-1494.533203},{"gnssid":2,"svid":25,"snr":23,"obs":"L7Q","lli":2,"locktime":0,"sigid":6,"pseudorange":26458929.665961,"doppler":522.487305},{"gnssid":0,"svid":6,"snr":26,"obs":"L2C","lli":0,"locktime":1260,"sigid":3,"pseudorange":25726852.080239,"doppler":2263.156006},{"gnssid":6,"svid":11,"snr":26,"obs":"L2C","lli":0,"locktime":11000,"sigid":2,"freqid":7,"pseudorange":22639928.606876,"doppler":1469.684814},{"gnssid":6,"svid":20,"snr":28,"obs":"L2C","lli":0,"locktime":100,"sigid":2,"freqid":9,"pseudorange":22154113.626381,"doppler":-2182.939697}]}
It is my understanding that I still need the orbital parameters out of the RXM-SFRBX subframe messages to compute actual satellite positions accurately in order to feed our tight integration system, but ??? I can go ask more questions if it sounds like I'm way off track here.