The Pycom LoPy Long Range Transceiver Part 2 Range Testing
This part discusses Range Testing as well as the Pymakr environment, developing, stability, and other evaluations that take time.
If you want the micropython code for the Oled display it’s here: github.
I’m going to start with the software stuff then talk about range.
Pycom now support Visual Studio Code with a plugin (as well as other IDEs that I don’t like as much). The plugin adds a number of commands (Run, Upload, Download, All Commands buttons are shown here on the bottom left).
General Pymakr Overview
I spent the first development time using manual methods to build. That went OK and eventually I found a reliable flow but it was never fun. The typical flow:
- Edit and save a file
- Go to FTP and update the file on the Pycom
- Reboot the Pycom via console or the little reboot physical button.
- Run Putty (telnet) and login (username/password).
- Paste in the file test code and run it.
- Rinse and repeat
Using Pymakr the typical flow is more like:
- Edit and save a file.
- Soft-boot the chip via Ctrl-D
- Click the update button which sends the changes to the project to the chip.
- Wait for the reconnect to time out then manually reconnect with Ctrl+Shift+C.
- Click the Run button to run the script file that tests
- Rinse and repeat
While these flows seem to have the same number of high-level steps, the second flow is a few keyclicks whereas the first is starting and stopping apps and relogging in and running FTP and … much much less fun. Also, the terminal window on Visual Studio Code rocks. It doesn’t close on glitches unlike Putty and it auto-logs-in.
So Pymakr on Visual Studio Code is a huge win. Good product with some rough spots.
There are places where this system sucks.
Like many immature systems there are a large number of incorrect error messages. For example, at first I couldn’t sync my chip and the plugin reported a missing sync.py script. Nope — I just hadn’t set the sync folder right.
When the plugin fails after a while it starts reporting out of memory on the chip. Nope, the plugin just failed (well sometimes the chip runs out of memory too).
Some of these are annoying, some are fatal.
- After cold boot the Plugin always fails to reconnect and then times out after about 20 seconds requiring manual intervention. This just needs fixing in the plugin.
- Sometimes the plugin becomes inoperative and you have to restart VSCode.
- Sometimes you can’t log into the chip at all because it crashed hard and it requires a physical button. This happens when you overflow the buffer on pastes and when you download large files. This is 100% unacceptable. What if the chip is in the field? According to Pycom the watchdog timer is taken up by system functions so you don’t even have a heartbeat to restart the chip.
Not surprisingly, the Python system is memory hungry. On the LoPy 1.0 (which is what I have) there is 60KB free heap. That’s not a misprint. On my simple OledTest application I run out of memory consistently.
That’s why the warm-boot requirement before uploading. Since uploading is memory-inefficient it often crashes after an app-crash without a warm boot. This crash requires a physical button press.
The memory issue is critical and makes the chip virtually useless for any serious applications. Pycom recognizes this and their newer chips (LoPy4, FiPy, …) have more memory. The LoPy has — RAM: 512KB — External flash 4MB. The LoPy4 (a newer board which adds SigFox protocol) has — RAM: 4MB — External flash 8MB. I assume a coming LoPy v2.0 will have more memory.
The chips seem very stable from a hardware standpoint.
I’ve been powering one using clip-leads and that means power goes on-off in funny ways sometimes. It has had no trouble. Even plugging one into the expansion backwards didn’t hurt it.
Running a chip with LoRa on and WiFi on and using both 100% didn’t cause the chip to warm up at all. Wow.
The software is less stable. Perhaps I’m not trapping enough exceptions but LoRa randomly doesn’t start right and an infinite loop LoRa send loop sometimes runs 10 or 20 times then crashes with an EAGAIN error (?). Conversely I ran a pair-communication loop overnight and it did 26000 iterations of moderately complex code LoRa/Wifi code without a glitch.
The worst issue is that when I was first testing it would sometimes boot into the wrong partition and I’d lose my boot.py. It would then revert to an AP which again would completely kill it in the field. This shouldn’t happen.
Here’s a view of my handheld range tester :)
I have the LoPy talk to the Oled to display Rssi and Snr values. It shows the received RSSI from the other side as well — so both ends are displayed on the Oled as I walk or drive around.
This was harder than my usual package due to the ‘no LiPo charger’ thing on the chip.
Here’s an Oled view
Here the base RSSI was -138 and the portable RSSI was -136 with a Signal-to-Noise ratio of -17dB (!) I think. The other numbers are counters to keep track of dropped packets and so you can tell when it’s receiving.
As you can see, with a spreading factor of 12 it went down to nearly -140dB reception — really good. With a lot of trees and building it went 1000ft and with no ground planes on the antennas and me handholding one in the car. I’d call that very good. It was also better than the Adafruit Feather with RF95 module by about 6dB (the Feather had an untuned wire antenna and no ground plane — which I’d call very good performance as well).
The reason this is so impromptu and not-analytic — i.e. not my style at all — is that I’m rounding up a few boards to do a comparison of. That’s far more interesting than range testing in one or two random environments. I think the transmission of 915MHz RF through boundaries is well understood and comparing RF performance can be done in a more controlled fashion.