bGeigieZen - Logfile Error

[BRS_Maulwurf]

I´ve just performted the first measurements on the weekend and there appearing some strange lines and points on the map....

https://api.safecast.org/en-US/bgeigie_imports/63402

I was walking in the center of "Messe Düsseldorf" and only there (red circle).

But there is a line even crossing the river (blue arrows). These line has a altitude of 500m and increasing to 2700m. I dont know where this is comming from.

Has someone a explanation? There are even some single dots far far away.

Same problem also appears a day later:

https://api.safecast.org/en-US/bgeigie_imports/63403

I will edit the file and remove the dots/lines but this is strange. 

Are these aircrafts? Because the airport is right next to it and this would explain the raising altitute.

Best regards

Philipp

[BRS_Maulwurf]

somehow the pic doesnt show up

[Rob Oudendijk]

Phillipp

Thanks for reporting the issue. One other person mentioned it. 

We are investigating the issue and will keep you updated.

Regards

Rob Oudendijk

[Rob Oudendijk]

Phillipp,

I checked today, a drive I did today... 

Seems good and very accurate. https://api.safecast.org/en-US/bgeigie_imports/63435

Same firmware. 3.2.4

Regards

Rob

[Rob Oudendijk]

Phillipp and Cyrus,

Seems we are on to something. Due to the higher sensitivity of the GPS receiver we are getting many more satellites, and we are picking up different consolations.

Some details of the research from one of the GPS experts in the Zen dev team:

"The PDOP (dilution of precision) numbers are quite high in the Ireland log file, range from 180 to as high as 1,700. It's better in the BRS_Maulwurf file, but still high 150-1,500 (one jump to 2,000).

Since PDOP is based on the geometry of the satellites visible overhead, this tells me that it's probably not the conversion bug from earlier (but please check anyway). Might it be that the receiver is assuming it's in the Americas and turning on the geostationary SBAS that would be low on the horizon from Ireland and Germany?
I mentioned earlier having the GNSS subsystem choose its constellations based on the current region, roughly 120 degrees of longitude: Americas, Europe, Asia (exact split TBD)."

Regards

Rob Oudendijk

[Louis Bertrand]

Hello Phillipp, Cyrus and Rob,

First, Phillip and Cyrus, thank you for your patience in helping us troubleshoot this serious issue. 

I've been helping the Zen development for a few months now and delved into the whole GNSS mess. That was my hypothesis (fancy word for guess-timate) that Rob quoted. 

The GNSS receivers used in the Zen are more complicated and sensitive than the one in the Nano so there are more variables to consider, and to misconfigure. 
The approach I'm considering is to fine tune which constellation (fancy name for the different national GNSS systems up there, e.g. USA-GPS, EU-Galileo, etc.) or combination of constellations to follow. 

My first suspicion is that by enabling GPS, we are also using the GPS geostationary reference (Satellite Based Augmentation System SBAS) over the Americas, which would put it very low on the horizon for you, and susceptible to timing errors due to ionospheric interference. Rob's Zen in Japan would not "see" SBAS. As a "rule out", I would like to make a version that ignores the GPS SBAS geostationary reference.

In the meantime, if you could capture log files of wonky drives, that provides more information.

All the best,

 --Louis

[Jan Helebrant]

Hi,

we also experience some GPS "issues" with CzechRad but in our case these "bad points" occur at the beginning when the device gets few (3-4) satelites and the resulting position has hight error. But in our case it also has high HDOP. We have a HDOP threshold value set in RadiationToolbox QGIS plugin so I am probably going to decrease the value to say 700 or 800 to ignore all these wrong points (you might consider this also for the API import).

However in your ZEN LOG file the HDOP values for the outliers is surprisingly not that high... but at least in this case you can get rid of most of the outliers just by ignoring data points with only 3 satelites.

Some outliers still remain - no idea how to solve this automatically. In our case we do manual check (in QGIS) of all LOG files before uploading so we also do a cleanup.

regards

Jan

Dne pondělí 1. července 2024 v 10:51:22 UTC+2 uživatel pfinn...@outlook.com napsal:

[cyr...@gmail.com]

Louis,

Thanks for the info. I am currently working from home, so drives are not a often occurrence for me, but I am updating the code, adding debug statements, and observing what is being logged. If there are some features or settings, or additional logging you want to try I'm totally game to install it and send you results. I'm already adding PDOP and sat count to the sent data so I can observe in my local grafana. 

As time passes it does produce coordinates that are closer and closer to the actual location, but it does not seem to settle into the actual location, and PDOP doesn't seem to correlate to actual accuracy.  Dumping the nav sat types I see this:

NavSat type:G,svId:21,gnssId:0
NavSat type:G,svId:7,gnssId:2
NavSat type:E,svId:2,gnssId:0
NavSat type:E,svId:26,gnssId:2
NavSat type:G,svId:13,gnssId:2

But looking at the TeenyUbloxConnect code, a gnss id of 2 corresponds to a satellite type of 'E', while an id of 0 corresponds to 'G', but I'm seeing them intermixed in the ubloxNAVSATSVInfo_t data. Not sure what is going on there.

--
You received this message because you are subscribed to the Google Groups "Safecast Device Discussions and Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to safecast-devic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/safecast-devices/d0aae7c6-e309-4868-8727-43e4bba70224n%40googlegroups.com.

[BRS_Maulwurf]

Hi Luis,

thank you for the information.

I´ve put my two "trouble" logfiles in the attachment and upload the corrected/edited ones to the API.
I will have a look, when I can perfrom the next drive.

BR
Philipp

[cyr...@gmail.com]

Louis,

I'm not a GNSS nerd, so I don't really know the best constellations to turn on. It looks like the zen is just going with the defaults. I can turn off GPS and turn on Gallileo and some others, but I am not sure what the best ones to use are for far west Europe. Do you have any ideas?

On Wed, Jul 3, 2024 at 11:26 AM Louis Bertrand <louisber...@gmail.com> wrote:

[Rob Oudendijk]

Jan,

How did you get those nice tables out of the rad plugin?

Hugs and peace,

Rob

[Rob Oudendijk]

Jan,

Got it..

[Louis Bertrand]

Hi Cyrus,
I wouldn't wish the curse of becoming a GNSS nerd on anyone! I more or less fell into it for this development work. 

If you have the option, try only Galileo to see if that changes anything. Then maybe GLONASS alone. They're supposed to be "anything but USA", right? I'd be curious to see if it's something regional.

Thanks

 --Louis

[cyr...@gmail.com]

Louis,

Fair, it does seem like a bit of a rat's nest. That said, I have been trying to en/dis-able different constellations via the TeenyUbloxConnect API, but for some reason calls to _gnss.setGNSSConfig() to enable GLONASS or to DISABLE GPS return false, so I'm not sure if I'm using it correctly event with a 1s pause between calls. Still working on it though.

To view this discussion on the web visit https://groups.google.com/d/msgid/safecast-devices/44ef47aa-5ff1-4a54-bdb1-e3d6d2dec278n%40googlegroups.com.

[Jan Helebrant]

Yeah,

we are just using the native attribute table feature:

https://docs.qgis.org/3.34/en/docs/user_manual/working_with_vector/attribute_table.html

You can even export the layer to Excel if useful. :-) When we started to think about displaying the Safecast data in some (possibly even offline) viewer we first thought about using something lightweight but feature requests began to pile up gradually... In the end, we decided to use QGIS - maybe it has a more complex interface, but it can do a lot of things that we would otherwise have to develop from scratch in a lengthy and expensive way...

regards

Jan

Dne středa 3. července 2024 v 22:54:32 UTC+2 uživatel oudend...@gmail.com napsal:

[Louis Bertrand]

Hi Cyrus,

There are only some combinations that work, likely due to the different carrier frequencies (bands).

There's a good discussion of the possible GNSS constellations in the library that one of our colleagues developed:
https://github.com/BeakeS/TeenyUbloxConnect/blob/main/src/TeenyUbloxConnect.h

It starts at line 21.

The reference for that is the interface manual for the u-blox M8 series of receiver modules (386 pages of good fun). The relevant discussion is pp.12-14.
https://content.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_UBX-13003221.pdf

Hope this helps

 --Louis

[cyr...@gmail.com]

Louis,

Yes, I have seen that, but I have an M10 which supposedly supports 4 concurrent constellations (GPS, GLONASS, Galileo, and BeiDou). If I cannot turn GPS off then it is going to make testing the others more difficult. I am suspecting a bug in either the Teeny API or the underlying module, but I don't know how to diagnose that.

To view this discussion on the web visit https://groups.google.com/d/msgid/safecast-devices/88fab298-ae14-4f36-8342-5988a22b928an%40googlegroups.com.

[Louis Bertrand]

Hello Cyrus,

Have you tried disabling SBAS? This would be a test to rule out geostationary "augmentation" time reference satellites too low in your view to be reliable. Low elevation means increased ionospheric distortion leading to timing errors.

There's a good description of this in the M8 manual,  in section 5 "SBAS Configuration Settings Description". Search the u-blox site for document number UBX-13003221. 

All the best

 --Louis

[cyr...@gmail.com]

Louis,

I was hoping to configure SBAS to use a European mode, but I haven't gotten that far yet. I'll try disabling it entirely and see what happens.

To view this discussion on the web visit https://groups.google.com/d/msgid/safecast-devices/2f2822bc-49dd-42d5-8ea7-8fc96620203an%40googlegroups.com.

[BRS_Maulwurf]

I´ve just updated the Firemware to V3.2.5 and on the satelite display im getting more "G" (USA) Satelites than others, And Im living in Europe.

I´ve put the Zen on my balkony and let it running on one location for this night. Let´s see how accurate the tracking is.

Maybe Im getting false data again.

[Rob Oudendijk]

Philipp,

With the software of Micheal Beakes that runs on the bGeigieZen (https://github.com/BeakeS/TeenyGPSTestbed_C2/tree/main) you can set the satellites groups. 

But be careful with it. After you set it, the settings are stored in the BE-88oQ and will stay even when you power it down and install bGeigieZen V3.2.5 again.

Regards

Rob Oudendijk

[BRS_Maulwurf]

Mhhh i dont think that i want to tweek the Zen by myselfe. I will stay at the offical update side.

I just reviewd the test measurement from yesturday and everything is fine... No strange GPS points.

[Rob Oudendijk]

Philipp,

We will release new firmware for the Zen soon where you can set the region you are in and the selects the optimal constellation of the GNSS.

Also, we made option to set the DOP manual is needed. That means that you can set up the level of accepted Dilution Of Precision https://en.wikipedia.org/wiki/Dilution_of_precision_(navigation).

Regards

Rob

[BRS_Maulwurf]

Hi everyone,

just as promised. Here is a new logfile with corrupt datapoints.

[Rob Oudendijk]

Phillip,

I looked at the data, and it seems you have a lot of HDOP higher than 500 (in red). The Zen dev team made a fix that would filter out higher than 500. Please wait for the release of the fix. I also notice that you do not have so many satellites in view. That also will be addressed in future firmware, where you can select what constellation of Satellites you us. 

Regards,

Rob

[BRS_Maulwurf]

Hi Rob,

thanks for the explanaition. Yes, satelites are in my region rare. 

I was surprised by the latest news/udate on the homepage: "Fixed display bug that would not allow more than 32 satellites at the same time to be used for navigation". Im happy if i get more than 5...

Here can be the "corrected" logfile found. Some points may be still wrong, but the overall rout is correct.
https://api.safecast.org/en-US/bgeigie_imports/63723

BR
Philipp

[BRS_Maulwurf]

Just reuploaded the Log...

https://api.safecast.org/en-US/bgeigie_imports/63727

Somehow API shows still "Number of Measurements" = 0 ....

Not the first time with this error.