New Receiver From Hemisphere

You are on to something with the Ground Plane Size. As in many other things, big is better. However, with modern receiver engines I am not sure that it makes any discernible difference.

For background, every 3-db of gain doubles the signal strength.

Looking at specification sheets for different sized ground plane elements it appears to me that there is 2 db less gain on an i-80 sized ground plane than a X91+ sized ground plane. Does this result in a difference that you can feel in the field? I don't think so, there are too many other variables (constellation, canopy, types of satellites, multi-path) in the mix. However, I am quite sure that a smaller ground plane is not better than a big ground plane. But sometimes the X91+ does feel like it fixes more quickly than a smaller antenna.

BTW: If you have not checked out the BigAnt project, it is worth a look: [ BigAnt Link ]. It is a big ground plane experiment taken to the BIG limit.

In addition to Ground Plane Size, I think it is important when purchasing a receiver that an absolute type-mean antenna model (the kind that Geo++ produces) be available for PPP work. There are examples of receivers that have had relative NGS calibrations performed with L2 offsets that are substantially different than the robotic calibrations. This can sometimes lead to apriori solutions on short baselines that are off a wavelength.

When looking at the new Hemisphere/Carlson device, you need to be aware that it available from Carlson as a BRx6, from Hemisphere as a S321 and an identical cased instrument from Gintec (another sub-brand of Unistrong) which is being distributed by Geneq in North America. The device is available from Hemisphere/Carlson with the Hemisphere Athena engine and from Gintec with a Trimble BD-970 engine. The BD-970 is a mature GNSS engine with known performance, however the Hemisphere device utilizes the 'Athena' engine which can also receive the 'Atlas' L-Band corrections. (Hemisphere is a sub-brand of Unistrong. Unistrong recently picked up the European Stonex brand too.) Stonex sells a very similar receiver the S10 which appears to be BD-970 based too.

This multiple marketing / sub-brand approach seems confusing to me.

But back to performance, it is really-really-really hard to compare GNSS performance for top of the line instruments. They all are pretty close. My primary concern is the number of bad fixes that a receiver will get under canopy. They all get them, but in my testing under the tree in front of our office, I have found that some are 50 times more likely to report a bad fix (with low HRMS/VRMS) than others. Of course the speed of fixing is very important under moderate canopy (all of these engines appear to be about the same in open sky conditions.) A few years ago I coined the phrase 'Bad Fixes Quickly' which in general describes the weak engines, I am not sure if it is much better than 'Bad Fixes Slowly' as the Slowly makes fewer mistakes by design.

I believe that the Javad LS receiver's latest firmware is GNSS-centric. ShawnB will probably verify that.

I believe that the Javad LS receiver's latest firmware is GNSS-centric. ShawnB will probably verify that.

I'll jump in and comment that Mark is correct that the current firmware for the Javad LS is GNSS-centric. What that means is the receiver is fully capable of using Galileo and BeiDou, and QZSS, but currently are not utilizing those signals. They will be put into use when the constellations are ready.

Mark Silver, post: 396026, member: 1087 wrote: My primary concern is the number of bad fixes that a receiver will get under canopy

And, once you WATCH a Javad LS solve and discriminate, the BAD fixes (and throw them out) and the GOOD fixes (keep them), well, it'll make you shiver! I'd say that this single issue, is what MAKES a Javad fan. It is the HIGHEST confidence GPS that can be had at any price. The VERIFICATION in a Javad is the bomb.
I pay for my equipment, just like everybody else. I don't get paid to say that. It is a non solicited compliment.
Nate

Mark Silver, post: 396026, member: 1087 wrote:
But back to performance, it is really-really-really hard to compare GNSS performance for top of the line instruments. They all are pretty close. My primary concern is the number of bad fixes that a receiver will get under canopy. They all get them, but in my testing under the tree in front of our office, I have found that some are 50 times more likely to report a bad fix (with low HRMS/VRMS) than others. Of course the speed of fixing is very important under moderate canopy (all of these engines appear to be about the same in open sky conditions.) A few years ago I coined the phrase 'Bad Fixes Quickly' which in general describes the weak engines, I am not sure if it is much better than 'Bad Fixes Slowly' as the Slowly makes fewer mistakes by design.

I believe that the Javad LS receiver's latest firmware is GNSS-centric. ShawnB will probably verify that.

As far as I know the LS has always been GNSS-centric, if I understand your meaning. We've been able to fix with Glonass only from the beginning. I suspect this predates the LS for Javad, but I don't know for certain.

Regarding bad fixes:
I agree that all RTK receivers (that I am aware of) will produce a bad fix. The only way to avoid this is by setting the statistical standards so high that you simply will not get a fix at all in difficult environments. So now the question is how to filter those bad fixes from the good. The LS does this by brute force, repeating the fixing process over and over again displaying the candidates as it works, until a consensus is formed. Then the LS collects data without resetting engines for specified amount of time. At the end of this specified amount of time, the LS again resets the engines and checks the last fix against the initial consensus candidate proving the fix was good. I recommend a 180 second minimum observation time because I have seen the same bad fix repeat in rare instances for 120 seconds. However I've never observed it at 180 seconds. I believe the constellation moves just enough in 180 seconds for the multipath to change such that the same bad fix cannot be repeated. It may produce another bad fix after 180 seconds, but it will not be the same bad fix. There are other safe guards we have built in, but this is the primary procedural safeguard, repeating the fix, over and over checking for consensus. Typically in moderate canopy, you may only have one candidate, but in tougher canopy, you might occasionally get more than ten candidates. Using other systems you will have to manually do the same process until you see a consensus. Take a shot, drop the fix, take a shot. Inverse to see if they agree. If not, take another shot, inverse. Ad nauseum. It becomes impractical in many situations to do this, so we simply say "RTK doesn't work in the trees" when it's not really true. RTK does work in the trees, but the processes we have for verifying the RTK in the trees is often inadequate. As a solo surveyor I push RTK in places I would have never dreamed and I sleep well because I have enough checks to know that I have the right positions on my points when I leave the point. I know Mark has bragged a lot about the SP80. I trust Mark, so I'm sure it is immensely capable. I hope we can get together someday and have a head to head.