Differences in GPS behaviour

[aliubi]

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.

[jcaron]

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

[aliubi]

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

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]

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

[crumble]

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

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