Accueil › Forums › English › General Discussions regarding BT747

Error in BT747 with QSTARZ BT-Q1000X / LOG STATUS wrong

bt747user99's picture
Sun, 09/20/2009 - 22:03 — bt747user99

Hi, BT747 does not properly handle and display the log status of the QSTARZ BT-Q1000X. My observations are:

  1. The BT-Q1000X has two modes of operation: The switch on the left may be OFF -- the device is off NAV -- the device sends data via bluetooth and USB to the host but does not log anything LOG -- as NAV but in addition data are logged, i.e. written to the flash memory of the device.
  2. Logging can be checked via NMEA $PMTK182,2,7*<CHK><CR><LF>, i.e. QUERY_LOG_STATUS.LOG_STATUS. Bit 1, the auto-log bit, is set to 0 if the device is in mode NAV but 1 if the device is in mode LOG.
  3. BT747 properly displays the log status on the log_actions tab, if it is first connected to the device. It seems BT747 is using (2) to check this status and display it.
  4. One should be able to use NMEA to STOP_LOG and START_LOG, i.e. $PMTK182,5*<CHK><CR><LF> and $PMTK182,4*<CHK><CR><LF>, respectively. However, the BT-Q1000X does not work as expected. What is more, the device responds with $PMTK001,182,5,3 and $PMTK001,182,4,3 to the STOP/START command, i.e. with valid command / packet, and action succeeded. Nevertheless, the device does NOT stop logging. This can be readily checked:
    (a) One may check the LOG_STATUS, which shows that the device is still logging.
    (b) One may also use QUERY_LOG_STATUS.RCD_ADDR to see that is grows, which means the device is continuing to write data to the flash.
  5. If set accordingly, BT747 uses STOP_LOG to try to stop logging before it begins to download the data from the device's memory. After having sent the command, the display shows that logging stopped, contrary to the actual state of the device. -- Which is an error.
  6. The MEDIATEK document (MTK GPS Logger Library User Manual 1.2, dated 11/29/2006) I was using for my own investigastions, is pertaining to the MT3301. The BT-Q1000X has a newer chip. Maybe something has changed here. Well, I am not sure what to make of all this. It does not seem to hurt, that logging cannot be switched off -- as far as reading the memory is concerned. In this case, it all boils down to an error in the status that BT747 displays. But what will happen, if the flash is being formatted? The document says that AUTO_LOG will be switched off automatically. So no problems should occur -- right? Or is there an error in the command to switch off logging of the BT-Q1000X? Can one switch logging off -- with the proper command? -- By the way, does someone have a link of a new version of the document, applying to the MTK II? I would greatly appreciate it!
‹ I can't get my pictures geotagged and no error displayed Connecting to Internet via proxy ›
Sun, 09/20/2009 - 23:57 — mdeweerd
mdeweerd's picture

Hi Your post is pretty

Hi
Your post is pretty detailed and it looks coherent with observations by certain users of this device. BT747 doesn't seem to have a lot of effect on the device for turning it off. What I have seen in a log provided by a user is that the logging is actually turned off (reported by the device) and just a few instants later it is on again (also reported by the device). I guess that the firmware is doing that.

The 'autolog' bit indicates that the device is logging according to the speed/time/distance conditions. This can not be used as an indicator that the device is in 'nav position'.

At the time I started a Google Document to record the protocol with the device and this document is here. I've added some things new to the MTKII chipset - AGPS is new for example - but the document is surely not complete (and I did not add everything I know yet).

As far as I can see, you are saying that BT747 does not indicate the logging status correctly?! This can be checked and improved. Logging active is somewhat complex if you like. There is one 'bit' to activate logging and another to activate 'autolog'. I am not checking now, but I believe that BT747 indicates the value of the first bit. This autolog was/is hidden to the user in other applications and I maintained that. However, BT747 does/should try to activate autolog behind the scenes.

You've obviously spent some time to investigate this - any particular 'application' purpose in mind?

Mon, 09/21/2009 - 22:28 — bt747user99
bt747user99's picture

Hi, ok, I checked what you

Hi,

ok, I checked what you said:

After STOP_LOG I wrote a polling loop, checking Bit 1 in the LOG_STATUS. If the device is in LOG mode, this bit is 1 and it changes to 0 after STOP_LOG is sent and back to 1 after a while. The elapsed time (with 30 tests) has a mean value of 541 msec, mean square root of 29 msec, minimum 308 msec and maximum 828 msec.

The funny thing is, that the reverse is also true: If the device is in NAV mode, this bit is 0 and it changes to 1 after START_LOG is sent and back to 0 after a while. The elapsed time (with 10 tests) has a mean value of 584 msec, mean square root of 93 msec, minimum 260 msec and maximum 1000 msec.

I am no statistician, but these numbers seem to be compatible with some process of periodicity (of about) 1 sec, that is changing the status of the bit back to what it has been before STOP_LOG and START_LOG was called. No matter when I send the START_LOG / STOP_LOG command, with a periodicity of 1 sec I will on average have to wait (about) 500 msec until it is switched back.

I do not understand what you say about the meaning of the bit 1 of the LOG_STATUS. Something similar is written in the MEDIATEK document. My observation is the following:

In LOG mode, bits 1, 2 and 8 are set. The time/distance/speed conditions are 50/0/0 i.e. data are written to the flash every 5 seconds.

In NAV mode, only bits 2 and 8 are set. The time/distance/speed conditions are still 50/0/0. In NAV mode, no data are written to the flash.

On the other hand, in both, LOG and NAV mode the devices sends standard NMEA sentences with talker-ID GP to the host with periodicity 1 second.

So, independently of the time/distance/speed conditions, bit 1 of the LOG_STATUS seems to tell me, whether the device is writing data to the flash, or not.

I think it would be great if you could add your knowledge to your document and share it with the public. Unfortunately, if I follow your link I only get a page of google with some advertisement, but no document. But I think I know what you mean: If I am right, I found a PDF-Version on this page

Do I have a particular 'application' purpose in mind? Well, not yet. I am (still) new to GPS and in the good old days of the wild west would have been called a green-horn ;-) The best way to learn something is for me to write a program and try things out. And since I am new to GPS I also have to see what use I want to make of it. I have ideas but no clear view yet.

Mon, 09/21/2009 - 23:46 — mdeweerd
mdeweerd's picture

Hi My document is public, but

Hi

My document is public, but apparently the link changed: new link. It can use some updating regarding the few commands I discuss next:

PMTK182,4 and PMTK182,5 will enable/disable logging according to the time/speed/distance conditions.
PMTK182,10 and PMTK182,11 will enable/disable logging completely (I did not check this - restoring this info from my memory ;-) ).

Even when time/dist/speed condition logging is disabled, the logger will still commit stuff to the logger memory which I believe is no longer done when PMTK182,11 is done. Bit 8 and 9 of the log status are controlled by the latter, bit 1 is controlled by the first.

Bit 2 of the status indicates overwrite/stop mode.

Here is the code I currently use in BT747 to decode the status:

logStatus = JavaLibBridge.toInt(sNmea[3]);
setLoggingActive((((logStatus & BT747Constants.PMTK_LOG_STATUS_LOGONOF_MASK) != 0)));
loggerIsFull = (((logStatus & BT747Constants.PMTK_LOG_STATUS_LOGISFULL_MASK) != 0));
loggerNeedsInit = (((logStatus & BT747Constants.PMTK_LOG_STATUS_LOGMUSTINIT_MASK) != 0));
loggerIsDisabled = (((logStatus & BT747Constants.PMTK_LOG_STATUS_LOGDISABLED_MASK) != 0))
|| ((((logStatus & BT747Constants.PMTK_LOG_STATUS_LOGENABLED_MASK) == 0)));
setAvailable(MtkModel.DATA_LOG_STATUS);
postEvent(GpsEvent.UPDATE_LOG_LOG_STATUS);

I do not get the overwrite condition from the status 'register' because I use PMTK182,2,6 instead.

Wed, 09/30/2009 - 15:56 — mdeweerd
mdeweerd's picture

For the sake of completeness

For the sake of completeness of this thread:

Further analysis confirmed that the Qstarz BT-Q1000X disables/enables the logging status according to the nav/log setting of the 'on/off' button about once every second.  In between these 'resets', that logger confirms and performs the change when requested by BT747.  BT747 regurarly requests the current status from the device, and updates the GUI according to the latest response from the logger.

Currently there is nothing that can be done about it, unless there is a (currently unknown) command to override this behaviour.