@fsergeys said in Changing the GPS frequency and configuring which NMEA sentences the gps posts.: GALILEO and GALILEO Full satellites Do you know what the difference between the two is? Also I wonder what is the default configuration for the tracking system? I think the application note regardig I2c mentions to perform a dummy write after each command prior to get back to reading see my example here: https://forum.pycom.io/topic/2442/pytrack-and-gps-balloon-mode/3 and the sequence chart in the application note: http://www.quectel.com/UploadImage/Downlad/Quectel_L76-L_I2C_Application_Note_V1.0.pdf <- requires login. and here is the code to perform checksum testing yourself: requires the sentence to be a bytes object. def _checksum(self, sentence): l = sentence[0] for c in sentence[1:]: l = l ^ c return l def _test_checksum(self, sentence): if self._checksum(sentence[1:-3]) == int(sentence[-2:], 16): return True return False

sorry no clue, I am not using pycom devices anymore so I can't tell. Sorry.

@zceld I often see an issue like this when I have another atom window/tab open that is also connected to the same serial port. Can you make sure nothing else is trying to access the serial port?

@jmarcelino Thank, with sudo It works !!

@gruia-nichita You don’t need the deep sleep shield on the Pysense/Pytrack, that functionality is built in.

The library does say it will work with Micropython so reusing some of the code regarding OBDII protocol should be less difficult. However the library is designed for the ELM327 device. Unless you use the device, there will be effort into making the code work with your specific communication method, for example directly using the Pycom CAN interface.

@seb A) FiPy+PyTrack+LiPo-Battery (Not-Attached-to-USB3.0) 
Vin = 4.09~4.10 V 3V3 = 3.32 V B) PyTrack+USB-Serial-device (Attached-to—USB3.0) same port as A)
 Vin = 4.85 V 3V3 = 0.23 V C) PyTrack+USB-Serial-device (Attached-to—USB3.0) + Hotswap-in-FiPy same port as A) & B)
 Vin = 4.55 V 3V3 = 3.32 V D) PyTrack+FiPy+NO-USB-Serial-device (Attached-to—USB3.0) same port as A) & B) & C) same combo as C) Just unplugged USB from PyTrack, and re-attached it…
 Vin = 1.69~2.51 V 3V3 = 1.15~1.91 V Also, worth nothing is that if my hand slips with the measuring probes, I get it to “boot-up” by accidentally shorting GROUND & 3V3, and I get a USB-Serial-Devices on my computer [ergo like A), B) & C) …] … And then, I get the same Vin & 3V3 as C) Which makes me conclude that you’ve guys have a Firmware issue!!! … and not a “bad usb-cable” or “bad usb-port” … etc etc. For some reason, in the boot-sequence of the PyTrack Firmware, it choose not to boot-up FiPy and enable USB-Serial … And, again, it’s odd that I can short GROUND & 3V3 with my measuring probes, and then it boots up FiPy and enables USB-Serial…

@meirssv you can save this info to sd card, flash or nvs

Hi @mongkol, so you have this error every time you try to update? Or just once in a while? I would suspect the PC USB port to be the problem, you could: change the USB-microUSB cable use the PC direct USB port, not thru a USB hub; remove other USB peripherals from PC The firmware update packages are sent over DFU protocol, which runs over USB bulk transfer channel, it might happen that the CRC of a package was wrong (or delayed).

@meirssv I've managed to construct a GPS tracker with a SiPy module. But I've use this gps lib ( https://forum.pycom.io/post/16183 ) from neuromistyx. Works great. because L76 is slow I've added a timeout of 3 minutes.

as @crumble say water level is probably not possible to mesure. If lat log is in pecision meters then you water level will be quite same.. Use different approach, there are many better ways for this task.

@jmarcelino Thanks for your respons, i figured as much but it is nice to have confirmation.

@dylan the memory problem is not useful for your issue. You get them somethimes with older firmwares. The GPS part uses a lot of strings. The garbage collector seems to handle them not always in a proper way. But I never ran into this issue when the LoPy got only power over USB. Maybe I was only lucky, or a watchdog solved it for me.

Every update seems to be different. This time, the PyTrack was detected as a COM device. With the same number as before :). But I was not able to connect. To fix it, I had to select show unconnected devices in the device manager, browsed for the usk driver and deleted the unknown and unconnected device.

@MJ On my Pycom.gpy I imported os, took a look at the directory, then os.remove('FILE NAME') >>> import os >>> os.listdir() ['sys', 'lib', 'cert', 'boot.py', '%1', 'test2.py', 'project.pymakr'] >>> os.remove('test2.py') >>> os.listdir() ['sys', 'lib', 'cert', 'boot.py', '%1', 'project.pymakr'] >>>

ouch... In Pycom's webpage, the last version of DFU that is writen is pytrack_0.0.4.dfu and I do not download because it's the version that I have now: "The latest firmware is v0.0.4. The DFU file can be downloaded from the links below:" But, if open the link, the version is 0.0.6.... Sorry, it's my fault! Works again!

@mj just to be clear, a GPS receiver needs to receive a good signal from several satellites for several minutes before it can give a position. The TTFF (time to first fix) may be even longer in some cases. This generally means you need to be outside (preferably not in a narrow street with tall buildings on both sides), with a good view of the open sky. In some situations you may be able to get a fix while inside close to a window, but YMMV significantly. Note that this applies to any GPS receiver. Phones are not good examples, as they more often get their position from wireless networks (cellular, Wi-Fi...) around them coupled with a database which maps visible networks to a position, and only revert to actual GPS in limited situations. That is not the case of a “pure” GPS receiver like the Pytrack which uses only GPS data received from the satellites. Haven’t used the Pytrack myself, but I suppose that like most receivers there’s a mode that would give you information about the satellites it sees, this can be helpful. Also don’t know if the Pytrack can save some of the information received (almanac, ephemeris...) and/or if there’s a way to supply it to the chip (A-GPS). If it doesn’t the TTFF can be very very long as some of the information required is broadcast by the GPS satellites at a very very slow rate and it can take over 30 minutes to receive the whole thing.