Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When Adding Additional Control Messages, Cannot capture PMTK001 Responses #9

Closed
askpatrickw opened this issue Mar 23, 2020 · 8 comments

Comments

@askpatrickw
Copy link
Contributor

I'm working to add sdditional control messages for:

  • Querying Firmware Version (605 - PMTK_Q_RELEASE)
  • Working with AlwaysLocate Flash Logs
    • Starting and Stopping Logging (185 PMTK_LOCUS_STOP_LOGGER)
    • Querying Log (622 PMTK_Q_LOCUS_DATA)
    • Erasing Log (184 PMTK_LOCUS_ERASE_FLASH)

But, as-is the library never seems to capture the response codes. These are all PMTK001 messages. Is this something you've observed before? I see you have commented out every place where you were trying to capture this before, ex:

    # return self._read_message(messagetype='001', debug=debug)

Any additional information you can share about that? I see in your new V5 version you switched to a threaded model. I am wondering if the _read was to slow in this model to catch all messages.

@andrethemac
Copy link
Owner

Correct. I couldn't capture those 001 request. Today I've tried to take some time to look into it. It seems you have to do the query first, wait for message 001 and then do your query again. The V5 threaded model is different and I have to take some time to see what/why I've done what I have done. The project has been silent for a while on my part (due to lack of time). I can't promise a quick fix. (It's a hobby). But I've got a good idea how to fix it.
best regards
André

@andrethemac
Copy link
Owner

Hi Patrick. I've been looking in to the messages. A few observations. The acknowledge message appear the first time then they don't reappear. The first time you ask something (like the version of the chip) it takes time (up to minute). Later questions are answered faster. Ive rewritten the parts so when you ask the version, the routine waits for an answer or a time out occures. The moment the library gets initicated (first use) the version is read out.This adds time to the startup.
At this time I'm using a part of the release or verion information to see what chip I have.
$PMTK705,AXN_3.10_3333_12102201,0000,QUECTEL-L76,*18 : out of this message I take the part after AXN (3.10) to see wat version I have and use this to add the new message options.
With this in your main.py you can see what the version of the chip is

from pytrack import Pytrack
from L76GNSV4 import L76GNSS
import machine, time
import pycom
print("up")
py = Pytrack()
L76 = L76GNSS(pytrack=py, debug=True)
print(L76.release)
print(L76.get_dt_release())

If you can tell me what you see, I can adapt the library.

best regards
André

@askpatrickw
Copy link
Contributor Author

askpatrickw commented Mar 24, 2020

I'll have a look... related thread with Quectel.
https://forums.quectel.com/t/determine-nmea-version-of-l76-l/3882/6

The person responding has been a little hard to follow, but they seem to be saying we need to use an undocumented PQVERNO command.

@askpatrickw
Copy link
Contributor Author

501
{
  'ProductModel': 'Quectel-L76L',
  'ReleaseString': 'AXN_5.1.6_3333_18060518',
  'PMTK': 'PMTK705',
  'BuildID': '0007',
  'SDK': '1.0'
}

@andrethemac
Copy link
Owner

Implemented the pqverno message, added NMEAversion according to chip version.
This is checked on init. (as the previous methode)
print(L76.NMEAVersion) to see what you get.

best regards
André

@askpatrickw
Copy link
Contributor Author

The line self.get_chip_version(debug=False) was commented out, so I uncommented it.

Here's the whole L76GNSS object which conveniently also has the PQVERNO response as the last message even.

{
    'reg': bytearray(b'\x00'),
    'ttf': -1,
    'lastmessage': {
        'ChipVersionID': 'L76LNR02A01SC',
        'time': '08:35',
        'date': '2018/07/23',
        'command': 'R',
        'PMTK': 'PQVERNO'
        },
    'NMEAVersion': 410,
    'timeout': 180,
    'BuildID': '0007',
    'chrono': <Chrono>,
    'SDK': '1.0',
    'debug': False,
    'ProductModel': 'Quectel-L76L',
    'ChipVersionID': 'L76LNR02A01SC',
    'ReleaseString': 'AXN_5.1.6_3333_18060518',
    'timeout_status': True,
    'Longitude': None,
    'timeLastFix': 0,
    'fix': False,
    'release': 501,
    'Latitude': None,
    'i2c': I2C(0, I2C.MASTER, baudrate=100000)
}

I'm going to run through a bunch of commands and will let you know if I see any issues.
I think with the new _query_pmtk there's an opportunity to use a lot more of the power in this chip. 👍 ❤️

Thanks!

@andrethemac
Copy link
Owner

Nice to see something I wrote is used. Hope you find some good use for it. I hope I find some time to do more with the GPS, but alas. On my todo list is still finding a fix for the long time to first fix on a cold boot problem. If you find something, allways happy to help.

@askpatrickw
Copy link
Contributor Author

More to ask about in the Quectel forum I suspect. Thanks again for the library. I'm going to look into the stored location logs and I'll look into the cold boot as well to see if there any tips\tricks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants