Solved: SiPy + PyTrack: GPS Example simplified to basic GPS only fails with MemoryError

[Meirssv]

I tested a bare minimum code sample for a GPS-test on a SiPy+PyTrack setup. This code (see below) fails after a while with MemoryError:

File "main.py", line 7, in
File "/flash/lib/L76GNSS.py", line 56, in coordinates

I found a reference to what I think is described in a bug post on the library here on github.

The SiPy+PyTrack is lying next to a window inside. If this is the reason for this issue, can we catch this kind of error and resume the code gracefully, so it will not interrupt the execution?

Is there someone who got the PyTrack working without exceptions?

from L76GNSS import L76GNSS
from pytrack import Pytrack

py = Pytrack()
l76 = L76GNSS(py, timeout=60)
while(True):
    coord = l76.coordinates()
    print("{}".format(coord))

[andrethemac]

@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.

[seb]

@robmarkcole

It can sometime take a while to acquire a lock. Try placing the Pytrack somewhere with a clear line of sight to the sky, such a window and leave it there for a few minutes.

[robmarkcole]

Picking up this thread, I want to read my GPS coords with my lopy. Using the following I get no data - I am inside the house so presumably this is just a reception issue?

from L76GNSS import L76GNSS
>>> from pytrack import Pytrack
>>> py = Pytrack()
>>>
>>> l76 = L76GNSS(py, timeout=60)
>>> coord = l76.coordinates()
>>> print("{}".format(coord))
(None, None)

[livius]

@meirssv
Thank you for confirmation
i have created pull request with the change
https://github.com/pycom/pycom-libraries/pull/43

[Meirssv]

@livius said in SiPy + PyTrack: GPS Example simplified to basic GPS only fails with MemoryError:

what if you change line 74 and 75 to

                if len(nmea) > 1024: # i suppose here can be safe changed to 82 which is longest NMEA frame
                    nmea = nmea[-5:] #   $GNGL without last L

Success! This is now running more then 12 hours and got a fix, without MemoryError. Thanks!

[Meirssv]

@crumble said in SiPy + PyTrack: GPS Example simplified to basic GPS only fails with MemoryError:

Hardware is working. If you look on the software, all is marked as beta. Reading the data from the GPS chip works fine. So you got all they promised.

You've got a point there... I was assuming these libraries were mostly finished libs, did not really think about it in that way.

[crumble]

@meirssv said in SiPy + PyTrack: GPS Example simplified to basic GPS only fails with MemoryError:

@crumble If you buy a PyTrack, especially designed to put on a LoPy or SiPy or WhateverPy, you'd expect the core function (GPS) to work with one of these Py-boards, I guess not.

Hardware is working. If you look on the software, all is marked as beta. Reading the data from the GPS chip works fine. So you got all they promised. Converting the GPS data in a format which is more user friendly seems to be the task of the community. The actual l76gnss library seems to be an example how to receive the data from the chip.

There is plenty of information from the GPS chip which the library does not deal with. Or there are features missing, like callbacks when you enter an area. But implementing the whole stuff means, that you waist a lot of RAM and flash. There is no linker which removes unused features. If we have such limited resources, we have to implement for each project only the parts we need.

Yes, the MicroPython part is much easier as reading the documentation of each chip and counting bits and cycles, but you still have to know what you are doing. Don't trust the propaganda ;) There will be never a system where you need no knowledge and skills to invent stuff.

Would an upgrade to the upcoming LoPy4 be a resolution? It has 4x RAM and twice the flash of the SiPy1 and it because it adds SigFox to the Lora radio, so it would be an alternative to the SiPy1?

Yes. Throwig hardware against the lib shall work.
And it will be much more as 4 times of RAM. A LoPy has around 64k free RAM. The newer models will have around 3MB. But additinally to the Guru Meditations we will get Chip and FastRAM again ;) (see the good old Comodore Amiga refernces) . OK, as far as I understood the MicroPython 1.9 docu, the external RAM is implemented as some kind of virtual memory. So we do not have to take care of it, unless we run into performance problems.

Maybe there are two solutions with the actual lib and old hardware.

• Reduce the timeout settings, so that there will be less strings created until a gc.colltect() is called. And call gc.collect() in front of the l76.coordinates()

• Place some gc.collect() in the lib. But this will be a performance decrease.

[Meirssv]

@crumble If you buy a PyTrack, especially designed to put on a LoPy or SiPy or WhateverPy, you'd expect the core function (GPS) to work with one of these Py-boards, I guess not. Would an upgrade to the upcoming LoPy4 be a resolution? It has 4x RAM and twice the flash of the SiPy1 and it because it adds SigFox to the Lora radio, so it would be an alternative to the SiPy1?

[crumble]

@meirssv the GPS example lib uses a lot of strings. So it uses too much memory. As well it uses only the GNSS sentence and not the GPS sentence. Some people seem to have problems getting coordinates. Maybe this is the cause. I was surprised that in my area I can receive GNSS indoor.

It would be nice, if pycom gives us a better library. I am currently try to fix this for myself using bytearray instead of strings. But beside that I have sparly time, I notice with every line why I hate python. Writing performant MicroPython is no fun. I know that I can rewrite 98% of my code as soon as it runs :-/

Beside that I miss an emulator, if I have some time and no device. There is still hope, that the next firmware gives us the 2nd core and MicroPython 1.9.x which may use less memory. It would be nice, if pycom focus more on the software than on new hardware.

[Meirssv]

@livius Seems sensible to me... I will give it a try later on, I am not in the office now. Will post feedback when available.

[livius]

@meirssv

what if you change line 74 and 75 to

                if len(nmea) > 1024: # i suppose here can be safe changed to 82 which is longest NMEA frame
                    nmea = nmea[-5:] #   $GNGL without last L

[Meirssv]

@livius Yeah... sorry, that's a typo. It was line 56, the nmea-append stuff... will change in my original post.

[livius]

@Meirssv
Is above error valid for lib from github https://github.com/pycom/pycom-libraries/tree/master/pytrack/lib or you have some modified/older version?
i ask because line 55 is break
which is not informative at all

[Meirssv]

@livius Yes, even tried that one, still same effect, it fails with memoryerror after a while. (Also running next to a window inside) -> I saw some responses on the forum with comparable PyTrack/MemoryErrors that it can be related to indoor use, but in the end, the code should not interrupt, it should gracefully handle the problem -even when using it inside-.

[livius]

@meirssv said in SiPy + PyTrack: GPS Example simplified to basic GPS only fails with MemoryError:
what if you change it to:

from L76GNSS import L76GNSS
from pytrack import Pytrack
import gc

py = Pytrack()
l76 = L76GNSS(py, timeout=60)
while(True):
     coord = l76.coordinates()
     print("{}".format(coord))
     gc.collect()