The Pycom LoPy Long Range Transceiver
I’m pretty interested in Long Range (LoRa) communications. Here I’m referring to use of the unlicensed bands (915MHz in the US, 868MHz in Europe). The Pycom specs and marketing stand out in a busy field.
The LoPy (as you can see) supports WiFi, Bluetooth and LoRa at 868/915MHz.
It’s not entirely clear what you need when ordering stuff. If you look carefully note that this chip, unlike most, has no USB port. It also has no LiPo battery port. In fact, it only has two antenna ports.
I like leading with the summary. I reserve the right to change this but as of (3/10/18) I’m impressed with some of the hardware and not as impressed with the software, support or documentation. Twice I’ve put the chip aside and swore I wouldn’t touch it again then browsed and found something to try and … ?
- The introductory documentation is just unacceptable. Browsing forums is not documentation. Even the technical references, while closer, are incomplete.
- The ancillary boards are not open source. That’s crazy.
- I wish this had a LiPo port.
- I really wish this had a USB port.
- Their forum support is just bad. Surprising.
- MicroPython as the shell is good and bad. I’ll know more later but it probably is slow and feature-poor and memory-hungry.
- The WiFi performance is very good.
- My first glimpse of the LoRa also looks very good but it will take more testing to know.
- The ESP32 has plenty of horsepower and memory.
- No physical keying is not good user design and so I totally plugged the second board into the expansion card turned around — but it seemed to have no ill effects. Thumbs up.
- MicroPython is simple, the libraries are relatively complete, and it’s easy to write a simple app.
So, not a winner at first glance but worth digging into.
I bought mine at Adafruit. I like them and the name. I bought a pair for obvious reasons.
Buy an expansion card! If you think you’ll survive without a USB connection — I think it’s unlikely. I bought one.
Here’s what my package looks like. Pretty sparse. A bag, a box, and a header-less board.
Here’s what it looks like inserted into the expansion board.
You can see I skipped one unnecessary pin. I had one snappable header of almost 2x the length lying on my workbench so, yeah.
The expansion board has zero documentation other than a pinout and mounting guide.
If you have a PC with wireless (like a tablet or laptop) the simplest setup is to use the expansion USB for power (or apply it manually to Vin/Gnd) and follow the non-expansion setup. If you don’t have a PC with wireless, follow the Expansion Board setup.
Starting with the Expansion Board
If you have an expansion board and headers on your LoPy, here’s how to get started. If you don’t have one you can skip to the “Connect to the interpreter” section and figure out how to power it yourself.
I used a lab supply to power my wifi-only test. The power requirement pulses and I had set the supply current clamp too low. It worked fine until my laptop connected to the LoPy AP and then the LoPy froze as the current requirement increased. Bad power supply choices will cause strange failures.
Prepare the Expansion Board
Ensure that all of the jumpers on the left, other than charge (CHG), are connected. Leave CHG open. That jumper enables fast-charge for LiPo batteries which seems like a bad default.
Insert the Chip
Insert the LoPy into the expansion board. Mount it carefully, there’s nothing guiding you except the pin labels — so make sure the labels on the chip pins agree with the labels on the expansion board (especially ground and vin). The fat LED goes over the USB connector.
Take a computer micro-USB output and plug it into the expansion board USB. The fat LED over the USB port should start blinking once every four seconds. If it stays bright white then you’re not supplying enough power. Mine uses 100mA with Wi-Fi connected but no LoRa and otherwise idle.
I use a LiPo battery with a coil for current sensing in series in the wires. It has a DC resistance of .06 ohms so works great except failed miserably for the expansion board. Once I put a cap in parallel with the coil it booted OK so the power requirement is varying rapidly.
Connect to the Serial Console
Assuming that you don’t have wifi on your pc, you must first type commands in the console to create a good boot.py file (the file executed at boot) that will put the LoPy on your network.
Serial Connection: The LoPy has (or simulates) a standard FTDI serial-to-usb chip and Windows has drivers for it. The FTDI site supports it for other OSes.
To enter commands, open up a terminal connection to the simulated serial port (in my case it’s COM6 at 115200 and I used Putty). When you press enter you should see the python CLI prompt >>.
Force the LoPy to join my Wireless Network
To have the LoPy join a ‘real’ network you have to edit the boot.py file located in the flash folder. This python file is run when the chip boots.
The Pycom has a neat feature called ‘Paste Mode’ (press Ctrl-E) that lets you paste multiple lines of python and then execute them all in one swoop. Enter paste mode then paste the lines from the file.
After pasting the lines, use Ctrl-D to parse/compile them and then run addmore() to create an entire boot.py file that starts by setting the UART and then initializes the network. After reset your LoPy should connect to the network.
To print your boot.py file contents:
with open('boot.py', 'r') as f :
To check your TCPIP configuration:
from network import WLAN;WLAN().ifconfig()
Starting without an Expansion Board
By default, the LoPy powers up as a wireless Access Point so if you have WiFi on your computer you can connect to it just like a router. If so, it will live at 192.168.4.1 (hardcoded apparently).
The documentation on FTP is adequate. Mainly, set it for FTP, no security ever, passive, no more than 1 connection. Pretty open FTP.
- Apply power to Vin/Gnd to boot the LoPy.
I used 4.9V and allowed plenty of current (1A?).
- From a tablet or laptop connect to the new lopy wireless network.
- Run Filezilla (see below) and transfer over the new boot.py so that it binds to your network.
- Reboot the chip and investigate OTA firmware updates.
Once you have FTP available, get the existing boot.py file then add this at the end (this is more or less from their online doc):
from network import WLAN
wlan = WLAN() # get current object, without changing the mode
wlan.init(mode=WLAN.STA) # switch from AP to device
# change the line below for ssid, security and password
wlan.connect('myssid', auth=(WLAN.WPA2, 'mypassword'), timeout=5000)
Reset and it should connect to the network and use DHCP to get an IP address and gateway/DNS.
Update the Bootstrap / Firmware
Like most of these devices the firmware changes rapidly. With a 1.0 device you must do the first firmware update via USB. From USB it goes like this.
Check your current version: to print the current version on your chip type:
Mine said: (sysname=’LoPy’, nodename=’LoPy’, release=’1.16.0.b1', version=’v1.8.6–849–055728a on 2018–02–13', machine=’LoPy with ESP32', lorawan=’1.0.0') as a result, which is very nice detail.
Get the latest firmware from the Pycom site. They are posted in the Forum (sigh).
Updating Firmware from Windows
Here’s the process for updating all firmware (including bootstrap) from Windows. This process requires a USB connection.
- Unplug the USB. Short pin G23 to ground. (G-TwentyThree). Plug the USB back in. It’s now in firmware update mode.
- Get the Espressif Arduino distribution for Windows. This contains a nice already working Esptool.exe in the Tools folder. Just copy that folder out of the github repository or zip. Installed for Arduino that folder is [sketch]\hardware\espressif\esp32\tools.
- Using 7-Zip or similar unpack the contents of Pycom’s latest firmware bundle:
a) appimg.bin — this is the ‘full’ image and placing it into the /flash/sys folder should cause an OTA on the next reboot
b) script — this text file shows what files go where. Read it.
c) bootloader.bin, partitions.bin, and lopy.bin are the three firmware files that I wrote to the device.
- Put the .bin files into the folder where esptool.exe lives just to make it simpler to type the command.
- Run a command prompt and cd [downloadfolder]\arduino-esp32-master\tools
- To write the firmware files run esptool as (use your com port, not com6)
.\esptool — chip esp32 — port com6 — baud 115200 write_flash 0x1000 bootloader.bin 0x8000 partitions.bin 0x10000 lopy.bin
Note the addresses were read from the script file.
7. Once the binary files are written: unplug the USB, remove the G23 short, and replug the USB.
You can do a non-USB update by running FTP and putting the appimg.bin file into the /flash/sys folder and rebooting. This did not work with firmware version 1.0.0, however, and that’s what ships on the chips for some reason — so you must firmware update via USB the first time. Also, it won’t update the bootstrapper as far as I can tell.
Making Terminal Reliable
I’m pretty sure you can add code to the boot.py file at startup that kills the telnet server and adds a new one with a much longer timeout. I did other things, none of which worked, and put it away until learning more. So, haven’t tried this.
Working with the Pymakr VSCode Plugin
I spent some time developing an application and got really tired of the FTP/Putty/reboot/FTP/Putty/… cycle. That prodded me to try the pymakr VSCode plugin (which I had downloaded but avoided after an initial unhappiness).
Now that my boards are connecting consistently to my WiFi network, and I’ve updated the pymakr.conf file manually to connect to my test board, the pymakr plugin is pretty neat. It has buttons to copy your changed project folder (and subfolders) to the board as well as the ability to run the specific file you’re editing.
So, if you work on one file at a time it’s an excellent environment. Even for more it’s not bad. Mine won’t connect right away after cold boot (it requires a wait…keystroke) but I’m starting to like this.
The worst problem is that it synchs via the USB port using the serial emulation. That’s unbelievably slow when, at least on this chip, they could just use the running FTP server at full wireless speed.
It defaults to 125Kbaud which just doesn’t work on my chips. They lag and the pastes fail and the file transfers fail and sometimes chip locks up or you just get bad code. At 19.2K no problem.
I really like MicroPython. I’m fairly sure that Pycom is using this distribution and their implementation does what you can to enable running without a USB connection. Having FTP and Telnet servers embedded, along with psRam support and multicore support really make MicroPython a usable operating system. Having an interpreted language makes debugging and development much faster.
After using the Pycom I have switched to using MicroPython for prototyping and testing new code. Programming in Python rocks compared with Arduino/C++. Debug, build, and test are all much quicker.
However… it is a high level language, documentation is very sparse, and I think it would be problematic to write a real commercial application with battery and performance and memory size issues. I couldn’t, for example, figure out how to change clock speed or disable a core or … lots of things you do with tiny processors in commercial applications.
For production use, for now, I’ll stick with C++.
What’s Next: LoRa — Long Range Communication
My entire reason for considering Pycom boards is their claimed advantage with LoRa. RF is hard and doing it well costs money for better parts and careful layouts.
Even if I don’t end up using the LoPy it is critical to have a Cadillac product to use for comparison.
So, the next step of the analysis is comparing RF front ends and transmitters.