Mro gps

Just gave me an idea. I want to force Ublox to 3hz and see what Pixhawk does.
 
  • Like
Reactions: JRW
Just gave me an idea. I want to force Ublox to 3hz and see what Pixhawk does.
Good idea. In the old solo ArduCopter, and ArduCopter 3.5, it probably won't generate any errors. But would probably degrade flight handling. In ArduCopter master (3.6-dev), it will give you a prearm failure.
 
Did you ever actually look at it through ucenter out of the box to see what was enabled out of the box? I'm curious if anyone has gotten one of these and looked.
Yes, and it showed USA GPS with waas augmentation, Galileo, and Glonass. That's why I say mine was sent out wrong possibly. After you get yours, I would be curious to see what it shows.
 
Configured or Enabled? Where are you looking in U-Center?
 
Configured or Enabled? Where are you looking in U-Center?
Enabled. I was looking at live data as it came in. I think the problem I had was I purchased it off of eBay from a third party. I looked at it before I upgraded to solex and 3.0 I have since sent it back and put a here GPS on a imp mast. Nothing but outstanding performance since i put the Here on. I was just going to put the mro on the imp mast, as he makes a shell for the mro, and rev 2 GPS, but I was having to many issues with mine. I would have bought Here from Jester, but he was out of stock when I bought mine. Frank.
 
Last edited:
Good idea. In the old solo ArduCopter, and ArduCopter 3.5, it probably won't generate any errors. But would probably degrade flight handling. In ArduCopter master (3.6-dev), it will give you a prearm failure.

I plan on throwing mRo on my spare Solo test test this, and keep the cover off to change GPS rate in the field from 3hz to 5hz.

Since I had my dual GPS Solo out, I set the mRo and HERE to just GPS and GLONASS only and tested (Usually GPS, GLONASS, Galileo). Kind of a pain to get HERE to change through tcp://localhost:500, but it will eventually stick. Few less sat's then normal but it flew about the same.
 
I plan on throwing mRo on my spare Solo test test this, and keep the cover off to change GPS rate in the field from 3hz to 5hz.

Since I had my dual GPS Solo out, I set the mRo and HERE to just GPS and GLONASS only and tested (Usually GPS, GLONASS, Galileo). Kind of a pain to get HERE to change through tcp://localhost:500, but it will eventually stick. Few less sat's then normal but it flew about the same.

That's been my experience using ucenter through the mission planner telem forwarder on the Solo. I suspect it is because the link quality sucks. I you hit the link stats button in mission planner up at the top right, you'll see it's something like 70-80% packet loss. That doesn't happen when connected to the pixhawk directly by USB. So the mro with the USB on top will definitely make testing this much easier.
 
Haven't tested this out yet at 3hz in the field but do get a lot of gps speed error messages that I dont get at 5hz.

Doing some reading of data sheets and looking at block diagrams.

The M8N has a dual frequency RF front-end architecture. GPS, SBAS, WAAS, EGNOS, MSAS, QZSS and Galileo all use the 1575.42 Mhz frequency and can share this band (L1C/A).

GLONASS and BeiDou both operate on separate bands (GLONASS 1602 Mhz L1OF band) (BeiDou 1561.098 Mhz B1l band).

Knowing that it's architecture supports two bands, and it is rated at two bands running at 5hz, GPS, Galileo and GLONASS should not be a problem. GPS (SBAS, WAAS, QZSS, etc.) and Galileo on 1575.42 Mhz band and GLONASS on 1602 Mhz band)

Sources

"u-blox8-M8_ReceiverDescrProtSpec_(UBX-13003221).pdf"
"NEO-M8-FW3_DataSheet_(UBX-15031086).pdf"
 
Last edited:
Knowing that it's architecture supports two bands, and it is rated at two bands running at 5hz, GPS, Galileo and GLONASS should not be a problem. GPS (SBAS, WAAS, QZSS, etc.) and Galileo on 1575.42 Mhz band and GLONASS on 1602 Mhz band)

Sources

"u-blox8-M8_ReceiverDescrProtSpec_(UBX-13003221).pdf"
"NEO-M8-FW3_DataSheet_(UBX-15031086).pdf"

Except the ublox documentation doesn't word the update rate specification based on band. It's by system. See 4.12 here. If you have GPS, the soviets, and Galileo enabled, it will drop to 3hz. I wish ublox described this in more detail. I think the part of the issue is Galileo and Beidou were still not fully deployed when most of their documentation was written, so it doesn't include much in the way of real world configuration examples.
 
Except the ublox documentation doesn't word the update rate specification based on band. It's by system. See 4.12 here. If you have GPS, the soviets, and Galileo enabled, it will drop to 3hz. I wish ublox described this in more detail. I think the part of the issue is Galileo and Beidou were still not fully deployed when most of their documentation was written, so it doesn't include much in the way of real world configuration examples.

Seems like the hardware should be able to run 5hz at least no problem, and U-center shows 5hz in UBX-CFG-RATE with 3 enabled. I'm surprised Arducopter doesn't log gps rate, or at least I can't see it anywhere. If 3.6 will know if it's set at 5hz, I would think some new hardware channel will be logged that isn't now.

Just doesn't make sense why the firmware would force 3hz, when the datasheets and CBD's don't mention this sort of limitation. The U-blox documentation reminds me of the Navy fleet where the software guys and hardware are not talking and the documentation doesn't make sense.
 
  • Like
Reactions: Saijin_Naib
The 3Hz rate is the "Solution Rate" not the rate that the data is sent to the "user". The solution rate is how fast the u-blox Cortex M3 CPU can process the RAW data from the RF/IF/correlator channels and derive a "solution" i.e. position. The update rate as set in UBX-CFG-RATE is how fast data is sent to the user over the serial/USB/I2C data path (the PixHawk2.x/Solo uses serial at 38400baud). The Cortex M3 CPU most likely has several threads running in some form of an RTOS, one of these threads sends data to the user, one calculates GPS, another Glonass, Biedou etc. When the solutions are ready they are available to the CPU to send to the user. If the solution is not ready, previous data, or incomplete/incorrect data may be sent. u-blox is not clear on how this works (or doesn't).
The u-blox firmware doesn't force 3Hz, it just can't compute the solution fast enough. That's why a single constellation can produce solutions at 10+ Hz, 2 constellations at 5Hz and 3 at 3Hz. This is also related to whether the firmware is running from flash or ROM. The internal ROM on the M8N (M8030 chip) is faster than the flash (which is external to the chip) so that effects the processing speed as well. ALL real u-blox M8N modules run from flash, mRo included. This allows you to update the firmware i.e 2.01 --> 3.01 whereas on many Chinese M8N's there is not any/enough/correct flash.
There are real ROM variants of the M8 module (M8Q, M8M) that don't have flash and some can produce solution rates up to 18Hz (for a single constellation). The unannounced M9 series probably has a higher speed Cortex M4(F) CPU that will put the M8 modules to shame as well as providing L2 support (in some form).
 
So that's actually the scenario that worries me the most. It will be sending 3hz updates at a rate of 5hz. So what is it sending? Bad data? Duplicate data? Nothing?

Given that unknown, it sounds like flight testing and log analysis is the only way show what happens. Regardless, this makes me even more confident that 3 systems on an M8 is a bad idea.
 
Last edited:
  • Like
Reactions: Saijin_Naib
I have ton's of logs with 3 running if anyone wants to look. Mostly with GPS blending though, but I can disable a GPS.
 
Good idea to analyse logs of 3 systems at once. Look for repeated results, truncated data (something ending in 000, 111, 222) as well as bogus positions in between good ones. u-blox doesn't say much to those that don't have a business relation ship (NDA) with them about anything inside their modules. There are undocumented messages that can be enabled to produce RAW data from an M8N that rivals the capability of the M8T, but folks have to discover how this works on their own, there is very little public info and that capability may go away in the next firmware release.
I'm not so sure if Solo logs will show anything interesting, .ubx format would be the way I'd start investigating, probably with 2 identical receivers driven from a common antenna + signal splitter. One receiver with 3 constellations at 5Hz one with 3 at 3Hz and maybe a third with 2 constellations at 5Hz. Receiver dynamics may be important too.
This could become a real science project it one is not careful ;>))
 
So that's actually the scenario that worries me the most. It will be sending 3hz updates at a rate of 5hz. So what is it sending? Bad data? Duplicate data? Nothing?

Given that unknown, it sounds like flight testing and log analysis is the only way show what happens. Regardless, this makes me even more confident that 3 systems on an M8 is a bad idea.
I got a spare new MRO (purple) sitting in one of my backup birds not doing anything. Knowing how you loathe to give MRO a dime, I'm more than happy to send you the MRO to play with, see what you come up with? Let me know, I'm always willing to make sacrifices for the greater good.... plus I'm waiting to order another HERE GPS in meantime anyway...
 
  • Like
Reactions: Wetstone
LOL. I did several shots and ordered one. It's in my mailbox waiting for me now. Thanks though.
 
No worries, just would like to get to the end of the mystery... aka bull... Depending on the outcome.... let us know when it appears on the classifieds..... :D
 
Now I *really* can't decide which way to upgrade before departure...
 
I have 4 Mro's using them as they come from Jordi so I am following this with great interest. All have worked fine and have not really compared them to my HERE.
 
Good idea to analyse logs of 3 systems at once. Look for repeated results, truncated data (something ending in 000, 111, 222) as well as bogus positions in between good ones. u-blox doesn't say much to those that don't have a business relation ship (NDA) with them about anything inside their modules. There are undocumented messages that can be enabled to produce RAW data from an M8N that rivals the capability of the M8T, but folks have to discover how this works on their own, there is very little public info and that capability may go away in the next firmware release.
I'm not so sure if Solo logs will show anything interesting, .ubx format would be the way I'd start investigating, probably with 2 identical receivers driven from a common antenna + signal splitter. One receiver with 3 constellations at 5Hz one with 3 at 3Hz and maybe a third with 2 constellations at 5Hz. Receiver dynamics may be important too.
This could become a real science project it one is not careful ;>))

This is with 3 constellations, but it's dual GPS (HERE and mRo). I can run with single GPS instead. But with this can see how both work with 3 systems running at once.

Dropbox - 2018-01-06 13-03-26.bin
 

New Posts

Members online

No members online now.

Forum statistics

Threads
13,095
Messages
147,750
Members
16,065
Latest member
alan r pfennig