New release New firmware release 1.2.2.b1

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?

minkley

@minkley
Still struggling to get the firmware upgrade to work on linux.

Note, I'm not using an expansion card but a Serial USB cable which powers the device up and allows me to connect to the wifi
I'm also able to connect to the serial port with minicom and I get the following python version:

>>> print(sys.version)
3.4.0
>>>

When I try and update the firmware I get the following error.

Namespace(file=None, port='/dev/ttyUSB0', speed=115200, tar='/tmp/tmp.zR12S6HK0s/update.tar.gz')
Connecting...
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 115200
Changed.
Exception: empty file, on line 131

This what I am doing exactly:

As root Downloaded and extracted pycom_update_1.0.0.b3.tar.gz

cd into pyupgrade
run ./update
select WiPy 2.0
Disconnect device from USB
Put G23 into GND
Plug in USB cable
Press and hold the the reset button for about 3 seconds
Press enter on the update
Type in the serial path :-> /dev/ttyUSB0
Deselect high speed

Then it fails with the "Exception: empty file on line 131.

Just to be sure my EMS32 connectivity is good, whilst connected via minicom, if I plug in G23 to GND hit reset, I see the device is waiting for a download

>>> ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

Perhaps someone can point me to the firmware file and a command line script I can use to test the install. I really would like to complete the upgrade and get on with using the device :)

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

New release New firmware release 1.2.2.b1

Pycom on Twitter