Weird GPS values

Bugs and Issues only for the Beta version of our apps and firmware
Post Reply
Dewcal
Posts: 10
Joined: August 27th, 2021, 11:02 am

September 2nd, 2021, 7:51 pm

Qstarz BLE with N2 on Z7-2 today - app not used even though updated to latest beta. On testing N2 with Z7-2, when QSTARZ was in fixed location, accurate fixes were sent to the camera. Time and date had been set on camera. One query, does the unleashed send time and date as well as co-ordinates? Note the change of camera model from my previous comments and these tests were part of setting the camera up for use.

On going outside (and QSTARZ in pocket) some images had fixes, some didn't. Interestingly many of the images appear to have been taken in "Nagari Kapar, West Sumatra, Indonesia" and on the following dates 2005-10-20, 2012-09-25, 2029-04-17, 2016-12-31, 2035-07-14, 2024-12-06, 2083-12-23, 2099-12-23, 2076-08-03 and a couple in 2021-09-02. All images were taken over a 30 minute period and I was not aware of any levitation.....

On checking the camera, the date had changed to 2053-09-21.

So not too sure what has been going on here! The Qstarz is running the latest firmware and gives a precise fix when linked to phone. I did NOT have the USB cable connected.
Any thoughts?
Dave
Oliver
Posts: 727
Joined: October 9th, 2018, 4:17 pm

September 2nd, 2021, 9:23 pm

Hmm, that is very weird.

- yes, the Unleashed does send the timestamp it gets from the GPS to the camera too, and you can choose in the camera menu whether you want to set the camera clock using the GPS time.
I suggest that you turn that off, if you're experiencing such issues.

We have had some reports of wrong locations before, but only at the very start of a session - my best explanation would have been that the Qstarz sometimes sends garbage data but marking it as good data, before getting a fix. Yours is the first report of the issue happening mid-shoot.

We'll get in contact with Qstarz to see if they changed anything in their Protocol recently, to see if we need to adapt anything.
Founder & CEO of Foolography, Hardware & Firmware developer.
Dewcal
Posts: 10
Joined: August 27th, 2021, 11:02 am

September 2nd, 2021, 11:22 pm

Hi Oliver,

Thanks for response. For some reason the camera does NOT have an entry for "Location Data" on the setup menu despite there being a reference in the user manual on page 478.
Willinvestigate further.
Dave
Unfoolishly
Posts: 297
Joined: June 24th, 2020, 2:43 am

September 3rd, 2021, 1:20 am

Hi All,

Maybe a good tip: send the log file on the memory card of the QStarz BL-1000ST to Foolography, so they can investigate the gps data. Also produce a file with the timestamps of the exif-info in each photo, so you get a list of gps coordinates combined with the timestamps. Then you can SEE which data is not being properly sent or received by the GPS receiver or Unleashed. At least by investigating this you come closer to the truth. Only thing is I don't know how to automatically (in a batch series) excavate the exif-data from the photos and produce a list out of it. But I am sure there is some (open source) tooling for that too. If there is an error-pattern to be found, it can be seen from the data.

I am positive that the data sent over Bluetooth is the same as the data on the memory card. If not, then QStarz has a serious problem.
With the data at hand you can zoom in on that part where it went wrong. Could be the Unleashed or the GPS receiver.

@Oliver: is it possible to connect to the QStarz receiver and fetch the complete log from the memory card and match that with all the embedded GPS data of the thumbnails sent to the smartphone (when used of course)? Why I ask is this: when doing a photo shoot, live debug the wrong-doing in GPS coordination writing in the photo, comparing two different datasets at the same time (from the Unleashed BT connection and the GPS receiver log). Okay, somehow a bit cumbersome, but is there a better/easier way? It would certainly be very helpful to bring the smartphone into this situation as an "independent observer" of GPS data received by the GPS receiver and the GPS data processed by the Unleashed itself. In other words: the BETA App containing some logging features for both the Unleashed and also (if possible) of the supported GPS receivers to fetch the log from the memory card.

You have three options for the smartphone in this situation:
1. let the smartphone connect to the GPS receiver over BT, log the GPS coordinates within the App, forward the GPS coordinates towards the Unleashed by the "smartphone to Unleashed"-connection. Sort of man-in-the-middle approach where the smartphone is the middleman.
2. let the smartphone connect to the Unleashed as an accessory (not as the "smartphone to Unleashed"-connection) functioning as a pass-through GPS receiver and thus test the Unleashed this way. You could use the internal GPS location data of the smartphone, or connect to the external GPS receiver and pass that on unto the Unleashed.
3. let the Unleashed forward the GPS data received from the GPS receiver (linked to the accessory connection) back to the smartphone over the "smartphone to Unleashed"-connection, thus creating the logging on the smartphone in the App like that. Sort of man-in-the-middle approach where the Unleashed is the middleman between GPS receiver and smartphone.

Yeah, it is complex in setup, but it sure gives you and all the users helping you in BETA testing enough tools to provide you with more debugging details. It's worth considering this to implement. Even if it is at first very basic in approach. Better have something to track, then nothing.


Good luck!

Greetings,
Unfoolishly
Retired customer of the Unleashed. I have given up on this project, it's a never-ending story of bugs. Goodbye everyone!
Dewcal
Posts: 10
Joined: August 27th, 2021, 11:02 am

September 3rd, 2021, 11:30 am

As an update, the camera menu DOES have an entry fro Location Data IF the N2 is conencted and the app is running..... Have now switched time from GPS off.
Oliver
Posts: 727
Joined: October 9th, 2018, 4:17 pm

September 3rd, 2021, 11:36 am

We also had this idea (looking at the logs) in the old thread:
viewtopic.php?p=1892#p1892

The Problem is that the Log only saves the good locations, whereas the bad ones are still transmitted via Bluetooth. But they are/should be marked as bad, so that we can filter them out.
Dave - could you send me the log file? The guys from Qstarz asked for it to have a look at as well!

However, I think that a false positive marking might have been the case for FrankU, where the time was correct, and the location had lots of zeros - that made me assume those are initialisation values.
But I don't think that's the problem here - where there is clearly very wrong data all over the place. That makes it look like we're completely misinterpreting the byte. I suspect this is because the data gets split into multiple Bluetooth packets, and the number and length vary depending on the number of satellites being used to calculate the position. I was sure we had that figured out correctly, and since this is the first such complaint after more than 2 years, that would confirm that we got it right. But if something changed, we'll need to adapt our interpretation. Lets see if we can figure out if something changed with the latest Qstarz Firmware update(s).
Founder & CEO of Foolography, Hardware & Firmware developer.
Unfoolishly
Posts: 297
Joined: June 24th, 2020, 2:43 am

September 3rd, 2021, 11:57 am

Oliver wrote:
September 3rd, 2021, 11:36 am
We also had this idea (looking at the logs) in the old thread:
viewtopic.php?p=1892#p1892

The Problem is that the Log only saves the good locations, whereas the bad ones are still transmitted via Bluetooth. But they are/should be marked as bad, so that we can filter them out.
That sounds like the QStarz GPS knows internally which locations are good and which are bad before they are written to the memory card. To me, it doesn't make sense that also the bad ones are still being transmitted over Bluetooth but the good ones are only written to the memory card. I would assume that the QStarz GPS receiver would also drop the bad ones over the BT connection and just swallow them up internally. Or both send and store the bad ones also.
Could you ask the developers at QStarz what they actually do in their firmware and if they changed any behavior between external (BT connection) and internal (memory card) communication? It sure sounds like the QStarz GPS receiver has to different behaviors within one device. That should not be the case. Why should you want the connecting device force to deal with bad data? Not logical at all as the sending party.

Greetings,
Unfoolishly
Retired customer of the Unleashed. I have given up on this project, it's a never-ending story of bugs. Goodbye everyone!
Oliver
Posts: 727
Joined: October 9th, 2018, 4:17 pm

September 3rd, 2021, 12:14 pm

Just because it doesn't make sense to you, doesn't make it a bad idea. 😜
I'd do the same! Getting data once per interval has always been done with all GPS receivers I have ever dealt with, and it makes perfect sense too: Even if the Unleashed might not be interested in bad data, an App connecting to the GPS might well be: if nothing else, just to display that the GPS receiver currently does not have a fix. However simply NOT receiving any data would be interpreted as a problem with the connection, (eg when at the edge of the Bluetooth range, packets might be dropped even if the connection is still there), and this case needs to be handled differently.
Founder & CEO of Foolography, Hardware & Firmware developer.
Dewcal
Posts: 10
Joined: August 27th, 2021, 11:02 am

September 3rd, 2021, 12:23 pm

Logs emailed
Unfoolishly
Posts: 297
Joined: June 24th, 2020, 2:43 am

September 3rd, 2021, 12:38 pm

Oliver wrote:
September 3rd, 2021, 12:14 pm
Just because it doesn't make sense to you, doesn't make it a bad idea. 😜
True. LOL!
Oliver wrote: I'd do the same! Getting data once per interval has always been done with all GPS receivers I have ever dealt with, and it makes perfect sense too: Even if the Unleashed might not be interested in bad data, an App connecting to the GPS might well be: if nothing else, just to display that the GPS receiver currently does not have a fix. However simply NOT receiving any data would be interpreted as a problem with the connection, (eg when at the edge of the Bluetooth range, packets might be dropped even if the connection is still there), and this case needs to be handled differently.
I would send all data as -1 value integers/bytes when no valid data was received, but we all know how de facto standards begin: somebody had a "brilliant idea" ;-)

Greetings,
Unfoolishly
Retired customer of the Unleashed. I have given up on this project, it's a never-ending story of bugs. Goodbye everyone!
Post Reply