please LOOK at the two supplied videos. the solution is in there
You may try tweaking the RX timing a little bit. This is possible with LMIC 1.5 arduino-2 using this code:
os_init(); // LMIC init
// Reset the MAC state. Session and pending data transfers will be discarded.
LMIC_reset();
// This tells LMIC to make the receive windows bigger, in case your clock is 1% faster or slower.
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
I had problems with non working OTAA on my LoPy after rogrammed in C++, not Python, and could solve this problem by adding the above statement. Without OTAA doesn’t work on my LoPy. Since LoPy has same ESP32 CPU as Heltec/TTGO boards this issue may apply on those boards, too.
Thanks @Verkehrsrot. Unfortunately, it didn’t work for me. I continue to see activation packets show up at TTN, but get EV_JOIN_Failed down at my non-working Heltec node.
OK so I could store and recover a variable from RTC memory. I had a look there to deal with LMIC ABP packet number persistance (so it’s also possible to store it in EEPROM, and keep it without any power).
But I still don’t know how to keep OTAA session open when deep sleeping…
I’m also looking at switching on screen at each start, keep it lit for 10 seconds and then switch it off, but using digitalwrite on pin 16 that initialized it, but not switching it off when turning it low again…
1 Like
Testing #ESP32 #LoRa Boards. Are they good? And what about the antennas?
note: Andy tested V1.0 of LiLyGO TTGO board. There is an improved version V2.0 available now. Shielded LoRa, better placed WiFi antenna, SDcard holder & battery management! https://de.aliexpress.com/store/product/2-St-cke-TTGO-LORA32-V2-0-868-433-Mhz-ESP32-LoRa-OLED-0-96-Zoll/2090076_32847443952.html
2 Likes
After an OTAA Join has finished, your node has the very same details you’d have for an ABP device. So: store the DevAddr, the secret session keys NwkSKey and AppSKey, the frequency settings, and keep track of both frame counters. See OTAA then ABP - #5 by arjanvanb.
1 Like
In his nice article Andreas uses a spectrum analyzer to measure LoRa performance of the boards. Finally we have some more hard data on what several people had already noticed: the sub-optimal LoRa performance of these boards. (Nice to see that this topic was used as a source for the article and is linked back to.)
I had a nice talk with Andreas during The Things Conference where we also talked about these boards. Andreas has not yet tested the TTGO V2, which I expect will have better LoRa results because it uses a standard LoRa module. Andreas was interested in also testing the TTGO V2 (but don’t expect any results soon because he has many other interesting projects waiting for him).
In response to the video:
It’s not clear to me whether the Heltec V1 or V2 was tested.
The part where the poor PCB antenna placement of the Heltec is discussed appears to be the Heltec V2 because it has the PCB antenna on the bottom (which is not connected).
Included antenna’s:
The LoRa antenna’s included with all Heltec and TTGO boards are (helical) monopoles. For a monopole the ground plane acts as the dipole counterpoise element.
The size and location of the ground plane will have significant impact upon the antenna’s VSWR and gain.
For a more representative judgement of the included antennas, the ground plane aspects should have been included in the testing. While most users will probably use the antenna just ‘as is’ and not take care for any proper ground plane, proper judgement of the antenna’s performance can still only be done when using the antenna’s correctly (and monopoles require a good ground plane for proper functioning because the ground plane is the counterpoise, it’s the other half of the antenna).
A larger ground plane will lower the resonant frequency and widen the bandwidth.
Which is exactly what could be observed in the video when Andreas touched the antenna’s ground connection with his hand.
Typically antennas are designed on a counterpoise that is one wavelength in radius.
Significant performance reductions occur when the radius is a quarter-wave or less.
Source: Linx - Understanding Antenna Specifications and Operation
For better performance: the performance of true dipole antennas does not rely on the presence of a good ground plane because the counterpoise is already included in the antenna itself. Like this antenna which is a true dipole: 868Mhz 19.5cm SMA antenna
(Btw, his name is Andreas, not Andy.)
Hi all.
As I’m tinkering around with ioT and LoRa, I bought a Heltec Wifi LoRa 32 868-915MHz. So far the small example files in Sketch work just fine. However, I run into some issues when trying to get the ttn-abp.ino example to work. It started with LMIC 1.5.0+arduino-0 failing as some constants where not defiined in the scope. So I installed LMIC 1.5.0+arduino-1 which does seem to work. Currently I used Matthijs’ arduino-lmic-master library and removed the IBM LMIC library. But now I get an error that no one else in this forum seems to have reported (don’t laugh):
"Guru Meditation Error of type LoadProhibited occurred on core 1. Exception was unhandled."
Followed by a register dump and a reboot, starting all over again. It seems to go wrong when calling os_init() (LMIC method). Does anyone have a clue what this could be? Honestly, posts that Google found on the matter are not that clear to me…
Thanks in advance.
Jean-Pierre
Example of full Serial Monitor log:
Rebooting…
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, 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:0x3fff0010,len:4
load:0x3fff0014,len:812
load:0x40078000,len:0
load:0x40078000,len:10164
entry 0x400789f8
Starting
Guru Meditation Error of type LoadProhibited occurred on core 1. Exception was unhandled.
Register dump:
PC : 0x40080de9 PS : 0x00060330 A0 : 0x800d0ed6 A1 : 0x3ffcffb0
A2 : 0x00000005 A3 : 0x00000002 A4 : 0x00000000 A5 : 0x00000000
A6 : 0x00000000 A7 : 0x00060223 A8 : 0x3f402468 A9 : 0xffffffff
A10 : 0xffffffff A11 : 0x0000006c A12 : 0x00000008 A13 : 0x0000ff00
A14 : 0x00ff0000 A15 : 0xff000000 SAR : 0x0000001a EXCCAUSE: 0x0000001c
EXCVADDR: 0xffffffff LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xffffffff
Backtrace: 0x40080de9:0x3ffcffb0 0x400d0ed3:0x3ffcffd0 0x400d30ab:0x3ffcfff0 0x400d0be7:0x3ffd0010 0x400dfd9b:0x3ffd0050
Another thumbs up for Andreas’ videos here - they are always excellent.
What I like about this one, is that he clearly demonstrates the Antenna problems on all 3 boards. TBH, I don’t feel the need to know a minor difference between them, as they are all have relatively poor antenna performance - I think the message is that we all have to wait for a better version to come.
However the excellent summary does say what the advantages are, and for many that is fine)
Another thing I like, is that Andreas shows a very practical example of how the antenna’s performance can be affected by the nearness of other objects (e.g. hand).
I’m also pleased that Andreas refers to this thread, I take it as being for people to read further background information away from his blog (which is very generous of him).
Andreas, if you’re reading these posts, just saying thanks!
1 Like
That better version (for LoRa at least) may already exist: TTGO V2 which uses a standard HPDTek LoRa module. But real measurements like in Andreas’ video will yet have to confirm that.
For how antenna performance can be affected, the above link to the Linx antenna article is an interesting read.
Have you tried the LMIC-Arduino library version 1.5.0+arduino-2 and its included ttn-abp.ino example when getting these results?
Have you used (and double checked) the exact same settings as described in the topic start?
Have you verified that all three parameters DEVADDR, NWKSKEY and APPSKEY are entered correctly and in the correct lsb/msb order?
I have a TTGO v2 and I am interested in running it for test as a single channel gateway.
Is this possible and which changes have to be made regarding the project https://github.com/kersing/ESP-1ch-Gateway-v5.0 ?
I am bit confused regarding the pin layout changes and not sure what is correct.
According to comments from Andreas’ below his video, it seems that he ordered a TTGO V2 to test it, so we will probably have these soon!
1 Like
Thanks @bluejedi,
A firm yes on first and third comment. I’ll have a double check on the used pins (tonight)…
Just giving a shout out for @nicbkw
Nice article!
https://www.thethingsnetwork.org/labs/story/heltec-lorawan-gps-quick-start
I’m thinking it would be nice to have another version of the code - which outputs the data to Cayenne and reports back RSSI to the OLED!
Before I have a go, has anyone done that?
2 Likes
One point regarding the OLED-display and multitasking with LMiC:
U8X8_SSD1306_128X64_NONAME_SW_I2C
This driver emulates I2C interface by software on GPIO pins. But on the Heltec the OLED-display is wired to pins, where the Heltec can do I2C by hardware. This keeps the CPU from load shifting bits on the wires. So better use:
U8X8_SSD1306_128X64_NONAME_HW_I2C
Regarding multitasking i found out that it is possible to let LMiC run on core 0 of ESP32 while application code (e.g. polling the GPS) can be run parellel on core 1. Of course you need to take care of possible race conditions in this setup.
3 Likes
Hi @bluejedi,
With regards to the “exact same setting as described in the topic start” I understand you refer to the pin mappings? lmic_pinmap lmic_pins I can find in the Sketch, but I’m lost with SPI.begin. Also, the inlcude for SPI.h shows SPI in red. Would that indicate there are multiple SPI.h found by Arduino Sketch?
Update: I’ve used the pin numbers as mentioned and get a failure on lmic\radio.c line 689 (if that is the actual source line then it says: " ASSERT(v == 0x12 );" for “#ifdef CFG_sx1276_radio”):
Starting
FAILURE
C:\Users\Jean-Pierre\Documents\Arduino\libraries\arduino-lmic-master\src\lmic\radio.c:689
-
This failure shows that either your pin mapping is wrong and/or selected chip type (1272 vs.1276) does not match.
-
You should not open the SPI interface in your code, since this done by LMiC.
-
If your board hardware uses non arduino style wiring of the SPI interface (MOSI, MISO, SCK) you need to patch the original LMiC code, or use the patched LMiC repo from jpmeijers, which enhances the lmic_pin_type struct.