Pytrack and Pysense firmware release 0.0.3 ??

[bartp]

I noticed when I wanted to upgrade my pytrack boards to latest firmware, the documentation mentioned 'latest version is version 3', which is also visible in pytrack filename (pytrack_0.0.3.dfu). However, in forum there is no mentioning of version 3 yet. Is there a changelog available somewhere?

I'm asking because after updating both LoPy to firmware 1.7.5b1 (latest version) and pytrack to 0.0.3 my main.py is no longer working correctly. I updated the libraries (pytrack.py, L76GNSS.py and LIS2HH12) to latest versions (commit 793bb64). It fails to instantiatie the Pytrack class:

from pytrack import Pytrack
from L76GNSS import L76GNSS
from LIS2HH12 import LIS2HH12

print('starting main')

py = Pytrack()   #LoPy hangs here, the 'py loaded' is never printed 
print('py loaded')
l76 = L76GNSS(py, timeout=120) # GSP timeout set to 120 seconds
print('l76 loaded')
li = LIS2HH12(py)
print('li loaded')

Is anyone else having the same issue?

update: I downgraded firmware to a custom version of 1.7.3b1 and now pytrack works again... Then I've erased flash of LoPy and updated to 1.7.5b1 again (using Pycom firmware update tool, having 'high speed mode' unchecked). And problem is back again. So @daniel I suspect something is wrong with 1.7.5b1.

[bartp]

@bucknall Sounds good! Ok, we gaan met jullie beren...

[bucknall]

@bartp On my current todo list is compiling a release notes page on our docs for LoPy/WiPy/SiPy Firmware, Pymakr Plugin, Pytrack/Pysense Libs and Pytrack/Pysense Firmware. Please bear with us as I'm involved in a number of different projects and am aiming to have this up by the end of next week, followed by updates to it every time we update any of those products

[bartp]

@daniel Confirmed! All is working nicely again! Thanks for the update!

Regarding the original topic; is there a changelog of Pytrack firmware 0.0.3 available?

[daniel]

Hello,

The issue with the readfrom_mem method has been solved. The new release is out: https://forum.pycom.io/topic/1423/new-firmware-release-1-7-5-b2

Cheers,
Daniel

[bartp]

@bucknall @daniel Ok, thanks! Looking forward to the new release.

[bucknall]

Hi all,

I ran into this bug yesterday upon testing and I'm pleased to share that it's been resolved now :)

Daniel will be releasing an patch for the bug later today, it was an issue related to readfrom_mem in the I2C class (1.7.5b1). I'll update here when it's patched and uploaded.

We're working on a methodology for better tracking releases and fixes. I have some ideas and thoughts on how we can best handle this publicly but am open to suggestions.

Thanks!

[bartp]

@jmarcelino @daniel Personally I think better documentation of what code needs to be updated is essential. I noticed there were updated libraries, updated pytrack firmware, so I assumed I had to update all of them to be 'in sync' with Daniel.

Perhaps it's best to reference to the corresponding change log in each firmware announcement, and mention any pytrack/pysense updated you need to do first.

Anyway, I've no doubts the engineers at Pycom are working full force to bring all promised features into the firmware.

[jmarcelino]

@bartp
Thanks, so it's unrelated to 0.0.3 and more likely an issue with I2C on 1.7.5, maybe to do with what @livius found.

Makes sense..

I'd hope Pycom would test their releases with their own official add-on boards. I think people quite rightly expect at least these to always work.

[bartp]

@jmarcelino Yes, I downgraded only the LoPy to 1.7.3b1. Pytrack (both modules I have) are running 0.0.3. That works ok.

[livius]

@daniel is this ok?

if (memaddr > 0xFF) {
        if (!mp_hal_i2c_write_byte(self, memaddr >> 8)) {
            goto er;
        }
    }
    if (!mp_hal_i2c_write_byte(self, memaddr)) {
        goto er;
    }

i ask about if (memaddr > 0xFF) {
if it is lower, then only one byte is written?

how device can distinguishe it then from data bytes?
I suppose that this if is unnescessary - but maybe i am wrong (i am not an expert).

[jmarcelino]

Ok that didn't last long, now Pytrack() also hangs consistenly for me. Not sure how it worked before.

Commeting the lines as @bartp said sidesteps the problem, until it fails for me with ValueError("Incorrect Product ID") on LIS2HH12. whoami is returning 0x00.

Are you still with Pytrack firmware 0.0.3 @bartp?

[jmarcelino]

@bartp

Umm I upgraded to 1.7.5b1 and 0.0.3 and Pytrack() loads for me, however LIS2HH12 fails with ValueError("Incorrect Product ID")

Anyone else?

I'll try to dig out the problem later if there are enough hours in the day...

[livius]

@bartp
I do not know if this is somehow releated
but addresses are two bytes in this situation and then are two call to mp_hal_i2c_write_byte
but this should not make any problem..

[bartp]

@livius I didn't get any error; program execution simply hangs.
If I commented out these lines in pytrack.py

    # init the ADC for the battery measurements
    self.poke_memory(ANSELC_ADDR, 1 << 2)
    self.poke_memory(ADCON0_ADDR, (0x06 << _ADCON0_CHS_POSN) | _ADCON0_ADON_MASK)
    self.poke_memory(ADCON1_ADDR, (0x06 << _ADCON1_ADCS_POSN))
    # enable the pull-up on RA3
    self.poke_memory(WPUA_ADDR, (1 << 3))

then program executions continues, but Pytrack accelerometer or GNSS functions returned all zero. As mentioned in my update, downgrading back to 1.7.3b1 fixes these issues, so i'm suspecting there is an issue in 1.7.5b1. I didn't downgrade the pyrack firmware (still on 0.0.3)

[livius]

@bartp said in Pytrack and Pysense firmware release 0.0.3 ??:

It fails to instantiatie the Pytrack class:

What error you got?
I did not updated already but this config work for me few days continously.
Wipy2 + 1.7.4 + pytrack_0.0.2.dfu