Tbeamv1 support

[nunomcruz]

Hi,

I added support for the TTGO T-Beam V1 by including a new board type in order to keep compatibility. The change will possibly also support other boards from TTGO, but I didn't test it.

The main driver to this was to use the Pycom integration of LoRaWAN with MicroPython since most of the implementations lack features and Pycom one is the most complete.

The PINs association were not mapped to pinouts at the T-Beam board since they are used along the code for setting things up.

[amotl]

Dear Nuno,

thanks for your contribution! We already picked this up at [1] and included your new target into our list of Squirrel firmware image builds [2] the other day.

So, anyone reading here not looking into building their own images might be happy to reach out to TBEAMv1-1.20.2.rc3-0.8.0-vanilla-squirrel.tar.gz.

With kind regards,
Andreas.

[1] https://community.hiveeyes.org/t/ttgo-t-beam/1848/4
[2] https://community.hiveeyes.org/t/squirrel-firmware-for-pycom-esp32/2960

[nunomcruz]

Thank you Andreas, glad the contribution helps Squirrel firmware!

[amotl]

Likewise. We hope the ready-made builds are helping the community. We just went down the rabbit hole of firmware building [1] and found it reasonable to pick up your contribution.

For ourselves, we don't use the T-Beam yet but recently started unlocking the T-Call for MicroPython [2,3,4] based on @sarusso's SIM800L.py. You might also be interested in that.

[1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/
[2] https://community.hiveeyes.org/t/micropython-libraries-for-the-sim800-module/1492
[3] https://community.hiveeyes.org/t/sim800-support-for-esp32-through-esp-idf/2983
[4] https://community.hiveeyes.org/t/unlocking-and-improving-the-pythings-sim800-gprs-module-for-micropython/2978

[elloza]

Dear @nunomcruz, thank you so much for your work! I have tested your firmware in a TBEAMv1 and it is working (I have tested ABP example from pycom).

In addition, I am trying to get that firmware working in another board TTGO LoRa32 V2.1 (and other variants).
https://github.com/LilyGO/TTGO-LoRa32-V2.1

I am getting this error after flashing the firmware.

Re-entered core dump! Exception happened during core dump!
Rebooting...
ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8018,len:4
load:0x3fff8020,len:2116
load:0x4009fa00,len:19408
entry 0x400a05ac
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x400827c1 PS : 0x00060330 A0 : 0x800d3040 A1 : 0x3ffe3c10
A2 : 0x00000000 A3 : 0x00000006 A4 : 0x00000008 A5 : 0x00000011
A6 : 0x3f4012b0 A7 : 0xc0100000 A8 : 0x3f401270 A9 : 0xc00fffff
A10 : 0x3ff49060 A11 : 0x00000b00 A12 : 0x00013ffc A13 : 0xffffffff
A14 : 0x3ff00044 A15 : 0x00000080 SAR : 0x00000015 EXCCAUSE: 0x0000001c
EXCVADDR: 0xffffffff LBEG : 0x40093c28 LEND : 0x40093c33 LCOUNT : 0x00000000

ELF file SHA256: `ffffffffffffffffffffffffffffffff8888888888ccffffffffffffffffffff

Backtrace: 0x400827c1:0x3ffe3c10 0x400d303d:0x3ffe3c80 0x400814ee:0x3ffe3ca0 0x400a0578:0x3ffe3cc0 0x400a067d:0x3ffe3e70 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20

I guess that I need to perform some changes to the current fork but I am pretty new in the inner workings of micropython and I was wondering if you could help or guide me in order to change it for make it work.
Thank you so much for your time! Great work!

[robert-hh]

You could try that firmware: https://github.com/robert-hh/Shared-Stuff/blob/master/HELTEC-WSLite-1.20.2.rc11.tar.gz
The TTGO board V2.1 is pretty similar to the heltec WSL, in that it uses a ESP32 Pico D4, which ikn turn needs GPIO16 and GPIO17. The usual no-SPIRAM ESP32 board define GPIO16 and 17 as regular pins, which causes the crash once GPIO is initialized.

Edit: @nunomcruz. You invested quite a bit of work in your port and that is well done. But you should not be surprised that Pycom has absolutely no interest in supporting other vendor's hardware, for various and good reasons. So don't expect your PR to be accepted. Bug fixes and improvements for the benefit of the Pycom product range are better recognized.

[elloza]

You could try that firmware: https://github.com/robert-hh/Shared-Stuff/blob/master/HELTEC-WSLite-1.20.2.rc10.tar.gz
The TTGO board V2.1 is pretty similar to the heltec WSL, in that it uses a ESP32 Pico D4, which ikn turn needs GPIO16 and GPIO17. The usual no-SPIRAM ESP32 board define GPIO16 and 17 as regular pins, which causes the crash once GPIO is initialized.

Edit: @nunomcruz. You invested quite a bit of work in your port and that is well done. But you should not be surprised that Pycom has absolutely no interest in supporting other vendor's hardware, for various and good reasons. So don't expect your PR to be accepted. Bug fixes and improvements for the benefit of the Pycom product range are better recognized.

@robert-hh Thank you so much for your advice! I have just tested it and micropython works well but I have tested the ABP example from pycom and I got another error [Errno 11] EAGAIN when it tries to send a message. I will research what it is happening. In any case, thank you so much for your quick answer 👍

[robert-hh]

I tested that on my heltec board and it worked. However there may be a difference in the LoRa section of the hardware. I could not find schematics of the TTGO Lora V2.1 board to be sure. I took some time to get the firmware running on the heltec device because I had not schematics of the Pycom unit of comparison. In the end if was the difference between the SX1276 clock supply, XTAL vs. XTCO. Just 1 bit in the configuration. I could prepare an image with XTCO setting for trial.

[robert-hh]

Created: https://github.com/robert-hh/Shared-Stuff/blob/master/TTGO2-1-1.20.2.rc11.tar.gz
That one uses XCTO. The other option could be the SX1276 reset pin. The heltec board uses IO14, the TTGO board seems to use IO23. If that's the case, it is floating. You could try to pull that up with a resistor to 3.3V. If that works, I can change the firmware to use IO23.

[nunomcruz]

@elloza Probably the main issue as @robert-hh already mentioned you need to adjust the pinouts, I can't remember all of them but at the time the main issues after adjusting pinouts was because of the SX1276 using the internal clock vs external, the same @robert-hh already mentioned.

@robert-hh I understand the PR won't probably be accepted, but at least there's some discussion here about how to port the firmware to other platforms :)

[robert-hh]

About pinouts: Yes, I forgot, there is more than reset, like all the interrupt pins.

[elloza]

Created: https://github.com/robert-hh/Shared-Stuff/blob/master/TTGO2-1-1.20.2.rc11.tar.gz
That one uses XCTO. The other option could be the SX1276 reset pin. The heltec board uses IO14, the TTGO board seems to use IO23. If that's the case, it is floating. You could try to pull that up with a resistor to 3.3V. If that works, I can change the firmware to use IO23.

@robert-hh thank you so much for your help. I have tried your firmware and I got the same error "[Errn 11] EAGAIN". I have also added a 1k ressistor between 3.3v but I haven't had any luck. I think I have found the schematics here: https://github.com/LilyGO/TTGO-LORA32/blob/master/schematic1in6.pdf

LED: IO25
LORA pin:
IO18=NSS/SEL
IO5=SCK
IO27=MOSI/SDI
IO19=MISO/SDO
IO26=DI0/IO0
IO23=IRQ/RESET

I am reading the source code of @nunomcruz in order to learn how it works, but it seems that i need more background in custom builds in mycropython and to read more!.

Thank you for your time!

[elloza]

@robert-hh, today I have received an Heltec WS (OlED version) and I have tested your last build HELTEC-WS-1.20.2.rc11.tar.gz and I am getting the same error when I test the ABP LoRa example. I dont know if any wiring is required or if I am doing something wrong :(

[robert-hh]

I have tested the Heltec WS package here and it worked fine.
Beside that, I have updated the TTGO2-1-1.20.2.rc11.tar.gz file to use gpio23 for reset. All other pins you mentioned were fine.

Edit: Here is my abp_node.py test script used on the Heltec WS. It is a little bit unstructured with some commented code lines, but it works. You have to adapt the setting for device ID and keys.

from network import LoRa
import socket
import binascii
import struct
import time
import config
from machine import Pin, WDT

# initialize LoRa in LORAWAN mode.
lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868, rx_iq=True)
# try to restore the state
if True:
    try:
        lora.nvram_restore()
    except:
        print("no data to restore")
        pass

if True: # lora.has_joined() == False:
    # create an ABP authentication params
    dev_addr = struct.unpack(">l", binascii.unhexlify('26012ED5'))[0]
    nwk_swkey = binascii.unhexlify('87D519A070A4E7BB313236463EFD30E1')
    app_swkey = binascii.unhexlify('7783760D9979C1F6C15B46C5150E6190')

    # remove all the non-default channels
    for i in range(3, 16):
        lora.remove_channel(i)

    # set the 3 default channels to the same frequency
    lora.add_channel(0, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)
    lora.add_channel(1, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)
    lora.add_channel(2, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)

    # join a network using ABP (Activation By Personalization)
    lora.join(activation=LoRa.ABP, auth=(dev_addr, nwk_swkey, app_swkey))
    print("Device was joined (again)")

    # remove all the non-default channels
    for i in range(3, 16):
        lora.remove_channel(i)

#

# create a LoRa socket
s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)

# set the LoRaWAN data rate
s.setsockopt(socket.SOL_LORA, socket.SO_DR, config.LORA_NODE_DR)
# selecting confirmed type of messages
# s.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, True)

# make the socket blocking
s.setblocking(False)

for i in range (200):
    pkt = input("Message: ")
    if pkt == 'q':
        s.close()
        lora.nvram_save()
        break
    # pkt = binascii.unhexlify(pkt)
    pkt = "PKT #{:03} ++++++++++".format(i).encode()
    print('Sending:', pkt)
    s.send(pkt)
    time.sleep(2)
    rx, port = s.recvfrom(256)
    if rx:
        print('Received: {}, on port: {}'.format(rx, port))
        data = lora.stats()
        print(data)
    # time.sleep(6)

And here is the config.py. Sometime I test other regions and frequencies, as you see:

""" LoPy LoRaWAN Nano Gateway configuration options """

import machine
import ubinascii

WIFI_MAC = ubinascii.hexlify(machine.unique_id()).upper()
# Set  the Gateway ID to be the first 3 bytes of MAC address + 'FFFE' + last 3 bytes of MAC address
GATEWAY_ID = WIFI_MAC[:6] + "FFFE" + WIFI_MAC[6:12]
# GATEWAY_ID = WIFI_MAC[:6] + "FFFF" + WIFI_MAC[6:12]

SERVER = 'router.eu.thethings.network'
PORT = 1700
# SERVER = 'eu1.loriot.io'
# PORT = 1780

NTP = "pool.ntp.org"
NTP_PERIOD_S = 3600

WIFI_SSID = 'B82'
WIFI_PASS = 'Den 20. Jaenner ging Lenz durchs Gebirg.'

# for EU868
LORA_FREQUENCY = 868100000
LORA_GW_DR = "SF7BW125" # DR_5
LORA_NODE_DR = 5

# for IN865
# LORA_FREQUENCY = 865062500
# LORA_GW_DR = "SF7BW125" # DR_5
# LORA_NODE_DR = 5

# for EU433
# LORA_FREQUENCY = 433175000
# LORA_GW_DR = "SF7BW125" # DR_5
# LORA_NODE_DR = 5

# for US915
# LORA_FREQUENCY = 903900000
# LORA_GW_DR = "SF7BW125" # DR_3
# LORA_NODE_DR = 3

[elloza]

I have tested the Heltec WS package here and it worked fine.
Beside that, I have updated the TTGO2-1-1.20.2.rc11.tar.gz file to use gpio23 for reset. All other pins you mentioned were fine.

I'm sorry, it was my fault, With your code it seems that there is no Errrn 11 anymore. Now, in the new firmware for TTGO v2 I'm not getting that error neither. However, I am not able to receive any packet from these devices (Wireless Stick and TTGOv2) on TTN. I have checked your source code with TBEAMv1 and @nunomcruz firmware and it is working like a charm.

I don't know why with TBEAM i am able to reach the gateway (uplink and downlink) but with TTGOv2 and WS i'm not receiving anything...

Anyway, thank you so much for your help! I'm very close to get it working because your support :D 👍

[robert-hh]

I assume that you registered these devices at TTN.

[elloza]

Yes, it is the same source code (the code that you have posted above but with my credentials) for all devices. I only get it working with TBeamv1 and @nunomcruz firmware.

With your firmware and your code I dont get any OSError but I dont receive any message in TTN console.

I'm using Heltec Wireless Stick V2.1 --> https://www.thethingsnetwork.org/forum/uploads/default/original/3X/7/9/79b506ab17f07ebd1c1cf6f511bc216a6c357c67.jpeg

[robert-hh]

That's strange. At least the Heltec WS should work, because I tested that with my Heltec device. And, sorry for asking the obvious, did you connect the antennas?
Did you disable the frame counter check in the TTN console?

[elloza]

You are right asking me for the obvious, sometimes I fail with most basic :) . I have double check, antenna and the options in the TTN, I have disabled frame counters checks, I have set 16 bit frame counter width and my keys are in MSB. However I got the same result...

It sounds strange for me too. That code works perfectly in the other board. I'm getting an RSSI of -115 and maybe the gateway is too far away...I don't know, becuase it is almost the same hardware...

Something that I have noticed it is that when I test the PYCOM ABP example, I get the OSErrn if I use this lines of code:

# make the socket blocking
# (waits for the data to be sent and for the 2 receive windows to expire)
s.setblocking(True)

If you think that I can check something or if you need more info, please let me know it :)

Thank you so much @robert-hh !

[elloza]

I'll see if I can get one of them! I will also test the two boards with a simple "hello world" in Arduino to exclude any hardware failure. thank you for your help @robert-hh 👍

[elloza]

I have tested TTGOv2 with an Arduino example and it works. However, I have tested WS with a simple example from here: https://github.com/rgot-org/TheThingsNetwork_esp32 but I have not had any luck...I am not receiving anything on TTN console. So it seems to be a hardware issue...I will try the SDR and I will check if the antenna is transmitting something... :(

[robert-hh]

If you go for the SDR receiver, you could also consider inverting another 10 € for one of these little logic analyzers. Very helpful in testing digital communication:
Sample link: https://www.amazon.de/AZDelivery-%E2%AD%90%E2%AD%90%E2%AD%90%E2%AD%90%E2%AD%90-Logic-Analyzer-gratis/dp/B01MUFRHQ2/ref=sr_1_3?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2EEJR9SD3TEZA&dchild=1&keywords=logic+analyzer&qid=1600841446&sprefix=logic+%2Caps%2C212&sr=8-3

[elloza]

Thank you @robert-hh for your advice! 👍
I have tested the TBEAMv1 with the SDR and it is working like a charm:

I'm learning how to use the SDR but I think that these signals are what I am looking for.

I have checked my WS and it seems to have some problem with the antenna because the signal seems too weak compared with previous one. Finally, I have returned the WS....

The TTGOv2 with your last firmware does not crash but it does not send the packet. I have checked it with an Arduino hello world code and it is working correctly.

Thank you for your help!

[robert-hh]

That looks good. Needles to say that the SDR is also a good radio receiver, with the audio decoders in the decoding section.
Since I lost track of which version I uploaded, I have made again two versions for TTGO with the assumed GPIO settings. One using the Crystal for clock, one usign the TCXO. Maybe one of these works.

[elloza]

Thank you @robert-hh! I feel like I'm making you work a lot, I'm sorry! I have tried both firmwares and neither gives me any error but I don't see any signal on the SDR either.

I have tested the same device with a Arduino code and I am receiving the data in TTN and seeing the signal in the SDR. I'm kind of at a dead end. Is there anything I can do to debug this? Is there a repository I can start from?

Thank you very much for everything!

[robert-hh]

I have tested the same device with a hardcode

Can you give a link to that hardcode? Maybe I see a difference.

[elloza]

Sorry, it was the spell checker, I meant "Arduino source code".

[robert-hh]

What's the link?

[robert-hh]

Maybe we could go another way. What I had to change for the ESP32 Pico D4 were

• not to touch GPIO16 and GPIO17
• reconfigure esp32lib.a, which is here: https://github.com/robert-hh/pycom-micropython-sigfox/blob/heltec/esp32/lib/libesp32.a
  Maybe @nunomcruz could try to rebuild his version of the firmware with the two changes above.

[elloza]

What's the link?

Do you mean the Arduino Source code Example? I was trying this repo for knowing if the board was working or not--> https://github.com/rwanrooy/TTGO-PAXCOUNTER-LoRa32-V2.1-TTN

[robert-hh]

Slowly I recall all the changes I made for the Heltec board. That is hard to blindly re-do for the TTGO board without testing. So I stop my attempt.

[elloza]

Don't worry, you've already helped me a lot @robert-hh . I will try to start from @nunomcruz source code to try to adapt it to the TTGOv2. Thank yo so much!

[elloza]

@robert-hh do you have published the source code for this release? --> https://github.com/robert-hh/Shared-Stuff/blob/master/TTGO2-1-1.20.2.rc11.tar.gz Maybe I could start from that point, at least with your release I am able to run micropython :) ! Thank you so much!

[robert-hh]

The base for that was the heltec branch: https://github.com/robert-hh/pycom-micropython-sigfox/tree/heltec
But you should get micropython at the TBEAM version running by.

• removing GPIO16 and GPIO17 from the pins.csv file of you board, and
• using esp32/lib/libesp32.a from my branch.

[elloza]

I made that changes and I'm getting this error:

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8018,len:4
load:0x3fff8020,len:2116
load:0x4009fa00,len:19408
entry 0x400a05ac
GC pool malloc failed!

:( I will keep trying

[robert-hh]

The Pycom port has no clean handling of SPIRAM and flash size. It assumes for Rev 1 CPUs 4 MB of SPIRAM and 8 MByte flash. You can fool that by changing the function esp32_get_chip_rev() in util/espchipinfo.c to return 0.Thats not elegant, but may work. I did more work around that in my port. Sometimes they also access the chipinfo structure.

P.S.: The message "GC pool malloc failed!" means progress, because that comes from the pycom firmware, meaning that it started fine.

[elloza]

Hello again @robert-hh! I have started to try from your heltec branch and I'm facing to an issue that maybe for you it's trivial but for a complete noob like me it's difficult to solve. I'm able to build your firmware and then flash it with:
make BOARD=HELTEC flash.
I'm getting the REPL and everything it's like in your firmware from "Shared Stuff" repo. However, when I push the reset button of the TTGOv2 i get this continuously:

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57

I don't know if I am missing something at flashing stage or what it's happening... In addition, due to my lack of background it is hard for me debugging this... :(

Thank you for your time!

[robert-hh]

You have to write:
make BOARD=HELTEC FLASH_SIZE=4MB
That's because the Pycom firmware assumes rev 1 chip boards to have 8 MB flash. So I added the FLASH_SIZE option to set it.
What you have to to in my Heltec port is to change all reference of GPIO14 to GPIO23, of GPIO35 -> GPIO33 and of GPIO34 -> GPIO32. For GPIO14, there are quite a few files related to it. If you look at the PR of @nunomcru you will see all the files,

[robert-hh]

Don't forget to call
make BOARD=HELTEC clean
before
make BOARD=HELTEC FLASH_SIZE=4MB
Otherwise the file in question, util/esp32chipinfo.c, will not be rebuilt. Instead of clean, you can also 'touch' that file.

[elloza]

Thank you very much @robert-hh. Now it is working properly and I have changed the pins as you told me. I would like to delimit the error. I have changed esp_log_level_set() in main.c and uncommented some printf() in modlora.c in order to get more info about what it's happening under the hood, but I hadn't luck... Do you recommend me to try something in particular? I feel that I am wasting your time and I probably will give up with this last try. (At least I have learned a lot along the way, thanks)

In addition, I have been comparing this pull request with your code and @nunomcruz set a lot of defines along the source code for their BOARD, i don't know if modify your branch in the same way...

[robert-hh]

Below is the list of file I have changed for the HELTEC adaption. In those except
for application.mk you have to look for the changes (assigning different GPIO Pins):

drivers/sx127x/sx1276/sx1276.c
drivers/sx127x/sx1276/sx1276.h
esp32/main.c
esp32/tools/makepkg.sh
esp32/tools/size_check.sh
esp32/boards/make-pins.py
esp32/lora/sx1276-board.h
esp32/lora/board.c
esp32/lora/spi-board.c
esp32/lora/sx1272-board.c
esp32/lora/board.h
esp32/lora/pinName-board.h
esp32/lora/sx1276-board.c
esp32/lora/gpio-board.c
esp32/mods/machpin.c
lib/lora/system/spi.h

esp32/application.mk

Some information is also in the file esp32/modified_files_heltec.txt, where I made some notes about the changes.

[robert-hh]

I went through the files and looked for what probably to change:

drivers/sx127x/sx1276/sx1276.c  No change required
drivers/sx127x/sx1276/sx1276.h  No change required
esp32/main.c                    ! Change gpio numbers 14->23, 35->33, 34->32
esp32/tools/makepkg.sh          No change required
esp32/tools/size_check.sh       No change required
esp32/boards/make-pins.py       !Change GPIO number 14 -> 23
esp32/lora/sx1276-board.h       Line 25 sets the Clock. 0x09 = Crystal, 0x19 = TCXO to be tested
esp32/lora/board.c              No change required
esp32/lora/spi-board.c          No change required
esp32/lora/sx1272-board.c       No change required
esp32/lora/board.h              No change required
esp32/lora/pinName-board.h      ! Change gpio numbers 14->23, 35->33, 34->32
esp32/lora/sx1276-board.c       No change required
esp32/lora/gpio-board.c         ! Change gpio numbers 14->23, 35->33, 34->32
esp32/mods/machpin.c            No change required
lib/lora/system/spi.h           No change required

esp32/application.mk            No change required

There is still esp32/boards/HELTEC/pins.csv. But that should be fine.
Note its GPIO33 and GPIO32, not GPI33 or GPI32

[robert-hh]

I uploaded again two variants (XTAL or TCXO) for trial with the changes I noted in my previous post.
Edit: I also made a ttgo branch in my repository on github. The board is still called HELTEC, so don't be confused. Renaming the board may be done later.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ nunomcruz
❌ Nuno Cruz

---

Nuno Cruz seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}