Hello @bq1, Try this [https://github.com/loboris/MicroPython_ESP32_psRAM_LoBo] (this Micropython) by Boris Lovosevic (Loboris). It has lora, telnet and ftp implemented.
Very interesting observations @bluejedi. I designed as ESP32 board with the ESP32-WROVER-B but I notice that whenever I flash it with Pycom firmware, firmware flashes, and boots the first time. Any reboot seems to either wipe or corrupt the firmware. I never figured out why that happened.
From my troubleshooting, there the PIN which the on-board RGB LED was connected seemed to be a part of the issue. I didn’t have a Lopy so I couldn’t confirm.
Did you notice anything different about the connection of the LED?
I was looking for some info on varying the CPU speed for the ESP32 whilst testing a high altitude balloon application and came across this post. My tracker board was setup for point to point LoRa, but the board could take a suitable sketch for TTN.
Its reported on here, and shows the tracker battery life for a 100maHr battery at various CPU speeds.
ESP32 LoRa tracker battery life.
I also measured how many maHr an ESP32 IOT node would use to send 1000 packets at bandwidth 125000hz, spreading factor 12, 14dBm, so typical for TTN. That is reported on here;
The test setup is here;
And the summary of power used is;
Power consumption of ESP32 IOT node, sending 1000 packets
ESP32 @ 240Mhz CPU speed using deep sleep 88mAhr
ESP32 @ 20Mhz CPU speed using deep sleep 45.3mAhr
ESP32 @ 20Mhz CPU speed using light sleep 38.2mAhr
ATMega328P @ 8Mhz CPU speed using deep sleep 35.7mAhr
Idle currents versus CPU speed
ESP32 @ 240Mhz CPU speed idle current 62.6mA
ESP32 @ 160Mhz CPU speed idle current 41.8mA
ESP32 @ 80Mhz CPU speed idle current 29.3mA
ESP32 @ 40Mhz CPU speed idle current 16.2mA
ESP32 @ 20Mhz CPU speed idle current 11.9mA
ESP32 @ 10Mhz CPU speed idle current 9.7mA
ATMega328P @ 8MhzCPU speed idle current 4mA
4 Likes
I own a TTGO LoRa Esp32 v2 and I am struggling to upload the new code (.bin). I treat it with really care, I was uploading and testing some codes and suddenly, it stop allowing me to upload new programs.
I have tried many different things and combinations of all of them:
- usb ports
- usb wires
- 2 linux
- windows
- arduino ide
- platformio
- pressing the RST button (it doesn’t have boot)
- changing the baud rate (upload speed)
- changing the flash freq
- changing the board type (TTGO Lora32 v1, v2, Heltec…)
And I get always this:
python /home/user/.arduino15/packages/esp32/tools/esptool_py/2.6.1/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0xe000 /home/user/.arduino15/packages/esp32/hardware/esp32/1.0.4/tools/partitions/boot_app0.bin 0x1000 /home/user/.arduino15/packages/esp32/hardware/esp32/1.0.4/tools/sdk/bin/bootloader_dio_80m.bin 0x10000 /tmp/arduino_build_119083/WiFiScan.ino.bin 0x8000 /tmp/arduino_build_119083/WiFiScan.ino.partitions.bin
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting........_____....._____....._____....._____....._____....._____.....____An error occurred while uploading the sketch
Failed to connect to ESP32: Timed out waiting for packet header
The weird thing is that I achieved loading sample programs like OLEDHelloWorld and it is working (showing that program in the OLED), but I cannot boot/upload any other program since that happened (yesterday).
Any idea?
(If answering this problem in this thread is not correct, I will open another post)
What IDE are you using? Based on the file path I would assume Arduino (and not PlatformIO).
/dev/ttyUSB0 so the OS must be Linux or MacOS (which one do you use)?
(Most of my experience is Windows based, so I may not be the best to assist you here.)
First of all, try a different USB cable (a known good one) this already may help.
What happens when you (USB) disconnect and connect the board?
What shows up in your devices list?
Is /dev/ttyUSB0 visible?
Have you connected more than one USB devices? (device enumeration is not guaranteed to be identical after each reboot).
Does lsusb give additional useful info?
What serial port have you selected in the IDE?
What happens when you press the reset button on the board (one or more times), does it make the board available in the devices list?
The most basic (example) sketch you can use is Basics/BareMinimum.
It will do nothing but you can compile and upload it.
Hi @bluejedi.
In my list of combinations/test I listed and tried with both Arduino IDE and PlatformIO (both in CLI pio run pio run --target upload and with CLion). But it is true that I posted the example with Arduino.
I tried also both in Windows (COM3) and in 2 different Linux distros (/dev/ttyUSB0).
Yes, If I disconnect the board (usb) it is powered off and the /dev/ttyUSB0 not listed (or COM3 in windows). If I connect it again, it starts using the latest uploaded program (yesterday’s OLED Hello World), the device (port) is again shown (ttyUSB0 or COM3) and I can try again to upload (but it fails with the Timed out).
This is the only device listed. I did not tried with more usb devices connected. But since you asked, I have tried. Eg. connecting an arduino uno in the USB0, and then the board (TTGO LoRa32 v2). The same happens when I get the ttyUSB1.
lsusb
Bus 007 Device 007: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
If I press the RESET button I can see the program resets (OLED HelloWorld) and while doing the upload using --trace I don’t see any difference (see below).
I have tried with BareMinimum too.
$ python /home/user/.arduino15/packages/esp32/tools/esptool_py/2.6.1/esptool.py --trace --chip esp32 --port /dev/ttyUSB1 --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0xe000 /home/user/.arduino15/packages/esp32/hardware/esp32/1.0.4/tools/partitions/boot_app0.bin 0x1000 /home/user/.arduino15/packages/esp32/hardware/esp32/1.0.4/tools/sdk/bin/bootloader_dio_80m.bin 0x10000 /tmp/arduino_build_642061/GetChipID.ino.bin 0x8000 /tmp/arduino_build_642061/GetChipID.ino.partitions.bin
esptool.py v2.6
Serial port /dev/ttyUSB1
Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
55555555 | UUUU
TRACE +0.000 Write 46 bytes:
c000082400000000 0007071220555555 | ...$........ UUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
5555555555555555 5555555555c0 | UUUUUUUUUUUUU.
TRACE +0.091 Read 1 bytes: 0d
TRACE +0.000 Read invalid data: 0d
TRACE +0.000 Remaining data in serial buffer: 0a0d0a
.TRACE +0.050 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
55555555 | UUUU
TRACE +0.000 Write 46 bytes:
c000082400000000 0007071220555555 | ...$........ UUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
5555555555555555 5555555555c0 | UUUUUUUUUUUUU.
TRACE +0.101 Timed out waiting for packet header
.TRACE +0.050 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
55555555 | UUUU
TRACE +0.000 Write 46 bytes:
c000082400000000 0007071220555555 | ...$........ UUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
5555555555555555 5555555555c0 | UUUUUUUUUUUUU.
TRACE +0.100 Timed out waiting for packet header
.TRACE +0.050 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
55555555 | UUUU
TRACE +0.000 Write 46 bytes:
c000082400000000 0007071220555555 | ...$........ UUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
5555555555555555 5555555555c0 | UUUUUUUUUUUUU.
TRACE +0.100 Timed out waiting for packet header
.TRACE +0.050 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
55555555 | UUUU
TRACE +0.000 Write 46 bytes:
c000082400000000 0007071220555555 | ...$........ UUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
5555555555555555 5555555555c0 | UUUUUUUUUUUUU.
TRACE +0.100 Timed out waiting for packet header
.TRACE +1.812 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
55555555 | UUUU
TRACE +0.000 Write 46 bytes:
c000082400000000 0007071220555555 | ...$........ UUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
5555555555555555 5555555555c0 | UUUUUUUUUUUUU.
TRACE +0.100 Timed out waiting for packet header
_TRACE +0.050 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
55555555 | UUUU
TRACE +0.000 Write 46 bytes:
c000082400000000 0007071220555555 | ...$........ UUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
5555555555555555 5555555555c0 | UUUUUUUUUUUUU.
TRACE +0.101 Timed out waiting for packet header
_TRACE +0.050 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
55555555 | UUUU
TRACE +0.000 Write 46 bytes:
c000082400000000 0007071220555555 | ...$........ UUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
5555555555555555 5555555555c0 | UUUUUUUUUUUUU.
TRACE +0.100 Timed out waiting for packet header
_TRACE +0.050 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
55555555 | UUUU
TRACE +0.000 Write 46 bytes:
c000082400000000 0007071220555555 | ...$........ UUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
5555555555555555 5555555555c0 | UUUUUUUUUUUUU.
TRACE +0.100 Timed out waiting for packet header
_TRACE +0.050 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
55555555 | UUUU
TRACE +0.000 Write 46 bytes:
c000082400000000 0007071220555555 | ...$........ UUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
5555555555555555 5555555555c0 | UUUUUUUUUUUUU.
TRACE +0.100 Timed out waiting for packet header
_TRACE +0.211 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
55555555 | UUUU
TRACE +0.000 Write 46 bytes:
c000082400000000 0007071220555555 | ...$........ UUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
5555555555555555 5555555555c0 | UUUUUUUUUUUUU.
TRACE +0.091 Read 1 bytes: 0d
TRACE +0.000 Read invalid data: 0d
TRACE +0.000 Remaining data in serial buffer: 0a0d0a
.TRACE +0.050 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
55555555 | UUUU
.... continue like this "loop" for 650 lines.
Edit: this issue is solved here (https://community.platformio.org/t/ttgo-lora32-v2-cannot-upload-timed-out-tried-many-things/14425) by connecting the IO0 with GND, although it needs now manual -slower- ops to upload and view the program (compared with previous normal -expected- behavior). But at least it works.
Thanks for your time @bluejedi.
Not exactly clear what you mean here.
The standard procedure to push the ESP32 into firmware upload mode is to temporarily connect IO0 to ground, then connect Reset to ground, release Reset again and then release IO0 again.
On ESP32 boards like the TTGO LoRa32 this is done programatically via the DTR and RTS serial port lines using a circuit consisting of two transistors connecting DTR, RTS, IO0 and Reset. The USB to serial adapter is integrated on the board. Connecting reset to ground can also be done with the reset button but the board has no button for IO0.
If you have problems with pushing the ESP32 board automatically into firmware upload mode via USB/Serial but it works when you manually connect IO0 to ground this may indicate a hardware defect of the board.
Could make sense to alter this topic ‘subject’ line…
This is a new TTGO LoRa32 V2.1.6 with SX1262 radio.
Datasheet (in Chinese) for the HPD16A module that was custom designed by HPDTeK upon request from LilyGO company (owner of TTGO brand) and SoftRF open source project.
1 Like
Yes, I was already considering that for ‘part 4’ of this topic.
Additional options and considerations are:
-
Continue this topic in a new topic “ESP32 LoRa boards part 4”.
In part 4 in the start topic, information available for each board will be presented in collapsed form as a list of board names. Clicking on a board name will then reveal the information for that board.
Bij collapsing the information, the start topic will not be cluttered with a long list of information for all boards. People are usually interested in only one board at a time and having to scroll information for all boards to find the information for a specific board is not exactly efficient.
Possible disadvantage: Will people then still be able to find the information they are looking for or will they no longer notice it and just quickly scroll over it? -
Create a separate topic for each ESP32 board (family) instead of having one main ESP32 topic (option 1)
That way board specific questions and information are concentrated in a single board-specific topic.
The disadvantage of this option is that ESP32 specific/generic information will be fragmented over several topics.
Which option would you (users of this ESP32 topic) prefer and why?
Are you using LoRa or LoRaWAN for SoftRF?
Which library currently supports LoRaWAN on ESP32 for SX1262?
I would personally vote for option 1:
“Big ESP32 +…” topic has a long history on this forum (since 2017, right?) and is one of the topmost popular threads here.
It aggregates every news that happens with LoPy, HELTEC, WeMos, TTGO and other LoRa ESP32 development boards on the market.
De facto, almost every of individual ESP32 boards has their own thread(s) here. But advantage of this particular one - this is the place where we can compare them.
1 Like
It was already answered here before.
SoftRF is using LoRa Phy layer / modulation to operate on so-called FANET radio protocol.
FANET is 1 out of 4 protocols supported. Other 3 are FSK modulation based.
FANET (LoRa based) is a standard feature of ‘factory’ SoftRF firmware.
However, one LoRaWAN ‘application’ - TTNMapper is included into SoftRF source code and can be activated by a custom build.
Semtech Basic MAC (successor of LMIC) derivative named ‘arduino-basicmac’ (adapted for Arduino by Matthijs Kooijman upon request from Lacuna Space) is known to work good enough on ESP32+SX1262 with TheThingsNetwork.
“Already answered … before”?
If you mean:
That does not answer my question above.
It is also hidden in a different topic in a post from 2 years ago.
I looked in the SoftRF README.md on GitHub but it does not mention anything about whether LoRa or LoRaWAN is used.
It is better to add that information to the SoftRF README.md than to hide it in some topic on this forum.
Of course. That slipped my mind, probably because I have not yet used it.
Hello,
I could also mention this library: GitHub - ngraziano/LMICPP-Arduino: Lmic (LoraWAN-in-C) modified to C++
“Add SX1262 chip”
Is it posible to buy this new TTGO LoRa32 V2.1.6 with SX12 62 radio somewhere ?
This SX1262 based TTGO T3 dev. board (a.k.a. “LoRa32”), as well as other updated “TTGO LoRa series” products (such as T-Beam, T-Fox, etc), are expected to appear in AliExpress stores within July.
This is an example of TTGO T22 (a.k.a. “T-Beam”) with HPD16A (SX1262) LoRa module:
Is there a particular reason or advantage for wanting to use an SX1262 ?
The SX1262 has some power advantages over the SX1276 in receive mode, but TTN nodes dont do a lot of time in receive mode.
Over these two years Semtech is aggressively pushing the 126x family onto the market and likely will cease some use cases of older 127x family in favour of the new one within a year or two.
High volume price tag of 126x IC is the same or less than 127x has.
One of the examples of the Semtech ‘arguments’ is that 126x family is best suited for upcoming ‘LoRa Space’ applications. Lacuna Space efforts are intended to prove that.
According to this ‘press release’ from RFThings : https://rfthings.com.vn/shop/ , Lacuna will (likely) NOT make their ‘Space dev. kits’ available in July as intended before but is going to slide them onto September.
If you want to do LoRaWAN over satellite with Lacuna you will need SX1262.