Differences in GPS behaviour



  • I just got two PyTracks and two WiPy4s, one set seems to work fine broadcasting its location once per second. The other set, running the same code, never seems to get a GPS fix, even though it seems to wait about 30 seconds each time. It seems like a hardware problem, but I wanted to see if anyone had any insight or experience with it before I sent the bad set back.



  • @crumble True, but it shouldn't reboot to the command prompt no matter what the source of the message, should it? @jcaron You're right, I'll post it in a separate thread.



  • @aliubi

    The successful iterations are when it was the only kid on the LoRa block. The crash occurs when I activate the other module,

    or someone else sends something. LoRa is like a CB radio. You receive every message which someone sends over your channel. ou have to find a way how you can identifiy your plain LoRa messages or connect to a network which will do this for you.



  • @aliubi you probably want to post a new question as this is quite unrelated to the original issue and title...



  • Okay, looks like I'm close on the break statement...here's the code, with diagnostic print statements.

    import machine
    import math
    import network
    from network import LoRa
    import socket
    import os
    import pycom
    import time
    import utime
    import gc
    import ujson
    from machine import RTC
    from machine import SD
    from L76GLNSV4 import L76GNSS
    #from L76GNSS import L76GNSS
    from pytrack import Pytrack
    
    time.sleep(2)
    gc.enable()
    pycom.heartbeat(False)
    pycom.rgbled(0x0f0300)
    
    rtc = machine.RTC()
    py = Pytrack()
    l76 = L76GNSS(py, timeout=30)
    #print("Trying GPS time")
    gpsTime = l76.getUTCDateTimeTuple()
    #print("Waiting for GPS time")
    while gpsTime == None:
        gpsTime = l76.getUTCDateTimeTuple()
    #print("Refining GPS time")
    gpsTime = l76.getUTCDateTimeTuple()
    #print("Setting GPS time")
    rtc.init(gpsTime)
    #print(l76.getUTCDateTimeTuple())
    pycom.rgbled(0x00000f)
    lora = LoRa(mode=LoRa.LORA, region=LoRa.US915)
    #lora = LoRa(mode=LoRa.LORA,region=LoRa.US915,frequency=915000000,tx_power=20,bandwidth=LoRa.BW_500KHZ,sf=12,preamble=8,coding_rate=LoRa.CODING_4_8,power_mode=LoRa.ALWAYS_ON, tx_iq=False, rx_iq=False, adr=False, public=True, tx_retries=1)
    #print('LoRa active')
    # create a raw LoRa socket
    s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
    #print('Socket set')
    
    locLoc = {}
    remLoc = {'a': 0, 'o': 0}
    s.settimeout(1)
    #print('Timeout set')
    
    while (True):
        # Get our location
        coord = l76.coordinates()
        #print('Got coords')
        # send to other unit
        locLoc["a"] = coord[0]
        locLoc["o"] = coord[1]
        if type(locLoc["a"]) != 'float':
            #coord1 = (0,0)
            locLoc = {'a': 0, 'o': 0}
        enc = ujson.dumps(locLoc)
        gc.collect()
        #print(enc)
        s.setblocking(True)
        #print('Ready to send')
        pycom.rgbled(0x0f0000)
        s.send(enc)
        pycom.rgbled(0x000000)
        #print('Location sent')
        # See if we get an answer
        s.setblocking(False)
        #print('Blocking off')
        pycom.rgbled(0x000f00)
        print('LED green')
        coord2 = s.recv(64)
        print('Stats coming...')
        lora.stats()
        print('Message received: {}'.format(coord2))
        try:
            print("Trying to decode")
            remLoc = ujson.loads(coord2)
            print("Restoring to tuple")
            coord2 = (remLoc["a"],remLoc["o"])
            if type(remLoc["a"]) != 'float':
                remLoc = {'a': 0, 'o': 0}
            print("Success, I think...")
            break
        except ValueError:
            remLoc = {'a': 0, 'o': 0}
        print('Message processed')
    
        pycom.rgbled(0x000000)
        time.sleep(1)
        print("{} - {} - {}".format(coord, coord2, math.atan2((locLoc["o"]-remLoc["o"])*math.cos(locLoc["a"]),remLoc["a"]-locLoc["a"])*180/3.1415926535))
    
    

    And the result:

    LED green
    Stats coming...
    Message received: b''
    Trying to decode
    Message processed
    (42.10828, -88.28986) - b'' - 0.0
    LED green
    Stats coming...
    Message received: b''
    Trying to decode
    Message processed
    (42.10836, -88.28994) - b'' - 0.0
    LED green
    Stats coming...
    Message received: b''
    Trying to decode
    Message processed
    (42.10838, -88.28993) - b'' - 0.0
    LED green
    Stats coming...
    Message received: b''
    Trying to decode
    Message processed
    (42.10838, -88.28994) - b'' - 0.0
    LED green
    Stats coming...
    Message received: b''
    Trying to decode
    Message processed
    (42.10839, -88.28994) - b'' - 0.0
    LED green
    Stats coming...
    Message received: b''
    Trying to decode
    Message processed
    (42.10839, -88.28994) - b'' - 0.0
    LED green
    Stats coming...
    Message received: b'{"a": 0, "o": 0}'
    Trying to decode
    Restoring to tuple
    Success, I think...
    Pycom MicroPython 1.18.2.r3 [v1.8.6-849-a1641ca] on 2019-02-28; LoPy4 with ESP32
    Type "help()" for more information.
    >>>
    

    The successful iterations are when it was the only kid on the LoRa block. The crash occurs when I activate the other module, which is running identical code. I guess I'm doing something so outrageous it can't even dignify it with an error message, but the only logical statement between the last print and the crash is "break." Again, I'm new to Python in general as well as to PyCom, so forgive me if it's obvious to everyone else.



  • @jcaron That particular problem somehow fixed itself over lunch the same day, now I'm chasing down something completely different...it resets unceremoniously when it gets a LoRa packet, but so far it seems it's not in the LoRa RX code, but later when I try to parse it (although this section is executed unconditionally). As far as I can tell, there's a "break" statement in my exception trapping that it's taking way, way too literally. Will post when I find out more.



  • @aliubi can you share details about your code and the firmware versions in use?

    Note that the GPS chip supports both GPS and GLONASS satellites but some libraries will only handle one or the other, so if for some reason the chip locks onto the one not supported you may not receive updates.


Log in to reply
 

Pycom on Twitter