New release New firmware release 1.2.2.b1

livius

@bmarkus
this is only not updated web page label
updater tool update to version expected 1.2.2.b1

mohpor

@daniel
Hi again,
Are we still up for today's update? (despite of the early 1.2.2.b1 update)

daniel

@mohpor the release is going to be out tomorrow (Friday 13), we still need one more day to complete all the features that we are targeting for this next release. Apologies for the delay...

Cheers,
Daniel

livius

@daniel
sorry for spam but good date "Friday 13" :)

daniel

@livius haha :-)

minkley

I think the latest firmware for Linux is borked :) It's my first hands-on with the wipy2 and the upater failed. Digging around I noticed there are no firmware files in the tgz.

There is no firmware directory as per the previous v 0.9.7.. version. I used this link https://software.pycom.io/findupgrade?product=pycom-firmware-updater&type=all&platform=unix&redirect=true

Here are the extracts so you can see what I am talking about.

tar -tvzf pycom_update_1.0.0.b2.tar.gz
-rw-r--r-- abiliojr/staff 247 2016-12-17 04:17 pyupgrade/README
drwxr-xr-x abiliojr/staff 0 2016-12-19 12:38 pyupgrade/bin/
-rw-r--r-- abiliojr/staff 0 2016-12-17 04:17 pyupgrade/bin/init.py
-rw-r--r-- abiliojr/staff 92013 2016-12-17 04:17 pyupgrade/bin/esptool.py
-rwxr-xr-x abiliojr/staff 4046 2016-12-17 04:17 pyupgrade/bin/updater.py
-rw-r--r-- abiliojr/staff 22135 2016-12-17 04:17 pyupgrade/lopyupdate.py
-rw-r--r-- abiliojr/staff 44124 2016-12-17 04:17 pyupgrade/spinner.gif
-rwxr-xr-x abiliojr/staff 7316 2016-12-19 19:14 pyupgrade/update

tar -tvzf pycom_update_0.9.7.b1.tar.gz
drwxr-xr-x abiliojr/staff 0 2016-11-26 08:44 pyupgrade/bin/
-rw-r--r-- abiliojr/staff 0 2016-10-27 20:13 pyupgrade/bin/init.py
-rw-r--r-- abiliojr/staff 92032 2016-11-26 08:19 pyupgrade/bin/esptool.py
-rwxr-xr-x abiliojr/staff 2408 2016-11-26 08:44 pyupgrade/bin/updater.py
-rwxr-xr-x abiliojr/staff 210 2016-12-03 05:12 pyupgrade/._firmware
drwxr-xr-x abiliojr/staff 0 2016-12-03 05:12 pyupgrade/firmware/
-rw-r--r-- abiliojr/staff 210 2016-12-03 04:31 pyupgrade/firmware/._bootloader.bin
-rw-r--r-- abiliojr/staff 5520 2016-12-03 04:31 pyupgrade/firmware/bootloader.bin
-rw-r--r-- abiliojr/staff 210 2016-12-03 04:44 pyupgrade/firmware/._lopy_0.9.7.b1_868.bin
-rw-r--r-- abiliojr/staff 828448 2016-12-03 04:44 pyupgrade/firmware/lopy_0.9.7.b1_868.bin
-rw-r--r-- abiliojr/staff 210 2016-12-03 04:43 pyupgrade/firmware/._lopy_0.9.7.b1_915.bin
-rw-r--r-- abiliojr/staff 828272 2016-12-03 04:43 pyupgrade/firmware/lopy_0.9.7.b1_915.bin
-rw-r--r-- abiliojr/staff 210 2016-12-03 04:32 pyupgrade/firmware/._partitions.bin
-rw-r--r-- abiliojr/staff 3072 2016-12-03 04:32 pyupgrade/firmware/partitions.bin
-rw-r--r-- abiliojr/staff 210 2016-12-03 04:46 pyupgrade/firmware/._wipy_0.9.7.b1.bin
-rw-r--r-- abiliojr/staff 820400 2016-12-03 04:46 pyupgrade/firmware/wipy_0.9.7.b1.bin
-rw-r--r-- abiliojr/staff 14383 2016-11-26 08:43 pyupgrade/lopyupdate.py
-rwxr-xr-x abiliojr/staff 5765 2016-11-06 03:32 pyupgrade/update

Or am I mistaken :)

Thanks guys

daniel

@minkley the updater now connects to the internet every time to get the latest files. Normally the updater prints an error message with the reason of the failure. Could you try again and copy paste the message here? Thanks.

minkley

Traceback (most recent call last):
File "./bin/updater.py", line 3, in <module>
from esptool import ESP32ROM
File "/home/mink/pyupgrade/bin/esptool.py", line 25, in <module>
import serial
ImportError: No module named serial

daniel

Ok, it looks like only the Windows and OS X updater tools come with pyserial bundled. Please install pyserial manually and run the updater again:

http://pyserial.readthedocs.io/en/latest/pyserial.html#installation

We will add this to the docs. Thanks.

Cheers,
Daniel

minkley

@daniel
Thanks Daniel
I installed pyserial it's getting past that now but failing with the following message

Namespace(file=None, port='/dev/ttyUSB0', speed=115200, tar='/tmp/tmp.nBBvLQ6mbC/update.tar.gz')
Connecting...
Exception: Failed to connect to ESP32: Timed out waiting for packet header, on line 121
root@pecan:/home/mink/pyupgrade#

So I guess the ESP32 is not live , perhaps you clarify something for about the firmware upgrade process. As I don't have an expansion but am using a USB serial cable, where does wipy2 get it's power from?

As an FYI, I'm using the same USB serial cable I connect to various other devices eg my CubieTruck3, so I know it works

Any guidance would be appreciated.

thanks

daniel

@minkley have a look here: https://www.pycom.io/wp-content/uploads/2016/11/wipy_pinout.pdf

You should connect 5V from the USB and GND. You also need to connect Rx and Tx on the program port. Don't forget to wire P2 to GND and reset to enter flashing mode as instructed by the updater tool.

Cheers,
Daniel

Feiko

Nano Gateway example doesn't work anymore https://forum.pycom.io/post/1210

It seems that calling lora_sock.recv(256) after lora_sock.send(pkg) is blocking the lora_sock.send function. The package is only send after the receive function is timed out. This kind of defeats the purpose of sending an ACK package. Does anyone have a solution?

Keep up the good work!

daniel

@Feiko have you by chance made the socket blocking?

lora_sock.setblocking(True)

Feiko

@daniel Here's my code. It's the same as in the example I added a timeout.

import os
import socket
import time
import struct
from network import LoRa

# A basic package header, B: 1 byte for the deviceId, B: 1 bytes for the pkg size
_LORA_PKG_FORMAT = "BB%ds"
_LORA_PKG_ACK_FORMAT = "BBB"
DEVICE_ID = 0x01


# Open a Lora Socket, use tx_iq to avoid listening to our own messages
lora = LoRa(mode=LoRa.LORA, tx_iq=True)
lora_sock = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
lora_sock.setblocking(False)

while(True):
    # Package send containing a simple string
    msg = "Device 1 Here"
    pkg = struct.pack(_LORA_PKG_FORMAT % len(msg), DEVICE_ID, len(msg), msg)
    lora_sock.send(pkg)
    
    # Wait for the response from the gateway. NOTE: For this demo the device does an infinite loop for while waiting the response. Introduce a max_time_waiting for you application
    waiting_ack = True
    timeout = time.time() +20
    while(waiting_ack and timeout < time.time()):
        recv_ack = lora_sock.recv(256)
    
        if (len(recv_ack) > 0):
            device_id, pkg_len, ack = struct.unpack(_LORA_PKG_ACK_FORMAT, recv_ack)
            if (device_id == DEVICE_ID):
                if (ack == 200):
                    waiting_ack = False
                    # If the uart = machine.UART(0, 115200) and os.dupterm(uart) are set in the boot.py this print should appear in the serial port
                    print("ACK")
                else:
                    waiting_ack = False
                    # If the uart = machine.UART(0, 115200) and os.dupterm(uart) are set in the boot.py this print should appear in the serial port
                    print("Message Failed")

    time.sleep(5)

The socket is not blocking.

Feiko

Of course I used

    while(waiting_ack and timeout > time.time()):
        recv_ack = lora_sock.recv(256)

On the NanoGateway side the package is received after timeout = time.time() + 20 is reached.

Feiko

In attempt to fix the NanoGateway code I tried locating the problem.
I used the next client code:

import os
import socket
import time
import struct
from network import LoRa

# A basic package header, B: 1 byte for the deviceId, B: 1 bytes for the pkg size
_LORA_PKG_FORMAT = "BB%ds"
_LORA_PKG_ACK_FORMAT = "BBB"
DEVICE_ID = 0x00


# Open a Lora Socket, use tx_iq to avoid listening to our own messages
lora = LoRa(mode=LoRa.LORA, tx_iq=True)
lora_sock = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
lora_sock.setblocking(False)

while(True):
    DEVICE_ID += 1
    # Package send containing a simple string
    msg = "Device %d Here" %DEVICE_ID
    pkg = struct.pack(_LORA_PKG_FORMAT % len(msg), DEVICE_ID, len(msg), msg)
    print("send message %s" % msg)
    lora_sock.send(pkg)

    # Wait for the response from the gateway. NOTE: For this demo the device does an infinite loop for while waiting the response. Introduce a max_time_waiting for you application
    waiting_ack = True
    timeout = time.time() + 20
    while(waiting_ack and timeout > time.time()):
        recv_ack = lora_sock.recv(256)

        if (len(recv_ack) > 0):
            device_id, pkg_len, ack = struct.unpack(_LORA_PKG_ACK_FORMAT, recv_ack)
           # if (device_id == DEVICE_ID):
            if (ack == 200):
                waiting_ack = False
                # If the uart = machine.UART(0, 115200) and os.dupterm(uart) are set in the boot.py this print should appear in the serial port
                if (device_id == DEVICE_ID):
                    print("ACK")
                else:
                    print("Ack with wrong device_id: %d" %device_id)
            else:
                waiting_ack = False
                # If the uart = machine.UART(0, 115200) and os.dupterm(uart) are set in the boot.py this print should appear in the serial port
                print("Message Failed")
    
    if waiting_ack:
        print('no ACK received')
        
    time.sleep(5)

This gives the next Console output:

Running node.py
Soft resetting the LoPy
send message Device 1 Here
no ACK received
send message Device 2 Here
no ACK received
send message Device 3 Here
no ACK received
send message Device 4 Here
Ack with wrong device_id: 1
send message Device 5 Here
Ack with wrong device_id: 2
send message Device 6 Here
no ACK received
send message Device 7 Here
no ACK received

Using the code nanogateway code from the tutorial found here gives the next console output:

Running nano_gateway.py
Soft resetting the LoPy
Device: 1 - Pkg:  b'Device 1 Here'
Device: 2 - Pkg:  b'Device 2 Here'
Device: 3 - Pkg:  b'Device 3 Here'
Traceback (most recent call last):
  File "<stdin>", line 28, in <module>
OSError: [Errno 11] EAGAIN

The package is received on the gateway side after the timeout is reached on the client side. Also the Ack for device 1 is received after the Gateway crashed.
Also after stopping the client and soft resetting then restarting the Gateway. There are still messages received:

Running nano_gateway.py
Soft resetting the LoPy
Device: 4 - Pkg:  b'Device 4 Here'
Device: 5 - Pkg:  b'Device 5 Here'
Traceback (most recent call last):
  File "<stdin>", line 28, in <module>
OSError: [Errno 11] EAGAIN

The receive buffer doesn't seemed to be reset with a soft reset. The sending of the ACK package from the server results in the OsError. After removing the

lora_sock.send(ack_pkg)

the gateway runs finds, however no Ack package is send.

Of course I used the latest firmware 1.2.2.b1. Can someone confirm my findings? I hope the problem can be fixed. I really need this code to run for a project.

iber

For me, the example code runs fine.
Although, I have noticed that your LoPy shouldn't be to close to eachother.
Maybe the long LORA wave has something to do with it?

bmarkus

@iber said in New release New firmware release 1.2.2.b1:

For me, the example code runs fine.
Although, I have noticed that your LoPy shouldn't be to close to eachother.
Maybe the long LORA wave has something to do with it?

Personal experience is with LoRa devices and gateways that it is easy to override receiver if they are very closed to each other equipped with antenna. In this case you exeperince a high packet error rate, lost packets.

Place them in few meter distance and disconnect antenna. It will not damage your chip but if you afraid use a dummy load or an attenuator between LoPy and antenna,

iber

I have to stand corrected, now that I'm running 1.2.2.b1 I can't get it working either...

Feiko

@iber Thanks Iber. I thought I was losing it. I Just went threw the trouble of putting the nodes 100 meters apart. Still no luck. Does your nanogateway also crash? putting in a little wait between receiving and sending the ACK message fixed this for me. Still the code shouldn't be crashing. @daniel Is this bug going to be fixed in the upcomming update?

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

New release New firmware release 1.2.2.b1

Pycom on Twitter