@jmarcelino

@jcaron I think I got it The calibrate_rtc() in library pycoproc break the console output, if I comment this call from get_sleep_remaining() No problem Connecting on COM24... # OK! starting, Reset= 0 stage 1 stage 2 Wakeup reason: 4 ; Aproximate sleep remaining: calibrate_rtc 0 sec stage 4 Wait for update ............. may be the deal is out there def calibrate_rtc(self): # the 1.024 factor is because the PIC LF operates at 31 KHz # WDT has a frequency divider to generate 1 ms # and then there is a binary prescaler, e.g., 1, 2, 4 ... 512, 1024 ms # hence the need for the constant self._write(bytes([CMD_CALIBRATE]), wait=False) self.i2c.deinit() Pin('P21', mode=Pin.IN) pulses = pycom.pulses_get('P21', 100) self.i2c.init(mode=I2C.MASTER, pins=(self.sda, self.scl)) idx = 0

@robert-hh I know :) it was a pic I took between :) I reinstall it and install latest plugin and atom.version still nothing

@jcaron Thanks a lot , limiting the channels to 0-8 and 64 ( for join/accept) did the trick for now.

@andrethemac Thanks for letting me know! Your library is just what I was looking for.

Also you have not checked if coord = l76.coordinates() return something it can contain None

@seb I notice that the cordination has abit delay first time you upload it... and it start working once you reboot it :)

@stefan85e Having Pytrack AND Wifi, you have two sources for the time: a) a NTP server. For that you have to espablish an internet connection. Look at the documentation & examples for WiFi and Internet access, Section https://docs.pycom.io/chapter/tutorials/all/wlan.html, heading: "Connect to a router". b) GPS. This is a little bit more tricky, since easy to use examples are missing. You can at least use the examples from thy Pytrack existing library and use that to derive the time information.

@robert-hh Thx, work kept me a bit busy but found some time to play today. I went the micropyGPS frozen module route. I've been running into issue after issue trying to get the dev environment up on OSX. So had to deploy a ubuntu box with all the tools first and flashed the new firmware from there. Preliminary tests show that the frozen module and the code works. Obtaining a GPS lock indoors not really yet however I need to look into it further. At least now I have more data/cmds to start troubleshooting. I have a Pi Zero with attached GPS module, 3G dongle and external GPS antenna which gets a GPS lock indoors fairly quickly and is using 3G to transmit coords so that's my benchmark. My goal is to downsize this tracker to sipy-pytrack-sigfox. Thx all for the pointers and support.

@fsergeys yes, we physically cut the header for that pin, so the only things that remain connected are the sensor and the PIC on the Pysense in our case. The LoPy was just bringing havoc when in deep sleep mode. You may want to experiment by using jumper cables between the WiPy and PyTrack at first, connecting everything but that pin, but I’m pretty sure you’ll get better results that way. Of course things would be very different with a WiPy 3, LoPy 4 or any of the other modules that implement deeep sleep directly rather than having to rely on an external board.

Could you use a battery and inductively charge the battery?

@buw I'm surprised that made a difference, I have nearly always upgraded Pysense boards with a module on. But whatever works for you!

@gregcope Wondering if it might be useful to simply start a thread for everything. If I spawn an alarm in one thread, an interrupt in another and so on, I may be able to avoid the issue of blocking. The major issue is that since some of the functions I need to run can take 20 seconds or so, I don't want one to block another from running and have to wait a whole other interval for the respective functions to be run. Especially since there are multiple interrupts and one or two alarms. So would simply running a function that spawns an alarm within a separate thread make it so that the alarm itself is contained in that thread indefinitely?

@xykon Hi I didnt't told you but have tried 1.16.0.b1 and 1.15.0.1 with both the same results. But with some wires soldered it is working fine. The following schema now is running: External IO Header : PIN 1 - GND PIN 4 - VCC 3V3 SENSORS Header(connected a wire underneath the board) P22 - SDA P21 - SCL I have now a working demo device for this week :)

@seb said in Pytrack PWR_EN, and 3V3 External IO pins: @gregcope Pin 3 3V3_Pymodule - This power supply is always switched on Pin 4 3V3_Sensors - This power supply is only switched on when the Pytrack is awake, when it goes to sleep mode it turns off Pin 2 PWR_EN - You can use this to externally toggle the sleep mode Old thread, but I need help: The pwr_en pin is to power down the pycom board right? Connect this pin to gnd with a button or with a switch?

@seb it looks like the pytrack button wakes the board only if you enable the accel wake up. Since I disabled the accel wake up the button does not wake up anymore. Can anyone can confirm this ?