Why double post? (see HOW TO CHECK THE REVISION LEVEL OF YOUR ESP32 above).
Hi @Verkehrsrot. When you spend a lot of money with a high-end manufacturer of industrial radios, one of the things that you are paying for is Quality Control and that all the radios will perform within stated limits and that radios that perform outside the stated limits will be discarded by the manufacturer and not sold.
You may well be seeing the natural wide-variability that comes from the manufacturing process and has not been QC-checked by a low-cost manufacturer.
The way that an industrial customer would deal with this situation is to do their own QC-check as part of purchasing and receiving the radios and to quarantine, reject and return any radios that do not meet the purchase specification.
3 Likes
@bluejedi Could you please also include the fixes/some information on the bad range of some boards in your starting post?
For example iirc some boards come with badly soldered resistors on the back or with broken antenna cables or whatever. I think those things might also be interesting for people who are starting to play around with those boards.
1 Like
Yes, you’re right, this is a general problem when sourcing directly from china.
But besides that, i’m surprised that the spread is such big, since the core radio elements are capsuled on SX1276 chip which has, i think, quality control.
1 Like
I have added a small note (only), because the issues appear to be more incidental than structural. (I try to keep the topic start general for an overview, the level of detail balanced, and yet as brief as possible.)
Hi,
Could you please advise whether it will be possible to use Heltec esp32 to read 433 Mhz Oregon sensors data?
thank you
I took a HopeRF and a Heltec board outside for a range test. We were hoping to get 4km, and we did easily with the HopeRF but only got 900m with the Heltec board. Took the modules back to the office and took a look on the SDR to see the Heltec’s RF levels 25dB less than the other LoRa modules at 915MHz.
20dB of that can be found in the amplifier (PA) that is on the HopeRF board that does not seem to exist on the Heltec board (couldn’t find a way to turn it on so perhaps it doesn’t exist) and the extra 4-5dB? Perhaps the filter is tuned for 868MHz and not 915MHz so their RFdesign is just cheap and nasty.
5 Likes
Nice idea to check with SDR.
Heltec has only one board for both 868 and 915 MHz so ‘not optimal’ seems a logical consequence (possibly not optimal for neither of the frequencies).
The TTGO V2 uses a LoRa module instead. So it will presumably have better LoRa RF than their V1 and the Heltec boards.
If the question is about the on-board SX1278 LoRa tranceiver (on a 433MHz version) the answer is: NO.
From a technical/theoretical perspective maybe, because the SX1278 also supports FSK/OOK modulation but my guess is that you will not find a library for that (which supports SX1278). The alternative is to use a separate more suitable 433MHz FSK/OOK receiver/transmitter for that.
You will be able to use a separate 433MHz receiver/transmitter with the Heltec Wifi LoRa 32, but that is out of scope for this topic.
1 Like
Also be aware of correct pin mapping. The SX1276 chips features two RF_out and two RF_in pins, one for low frequency band (e.g. 33 MHz), and one for high frequency band (e.g. 868 and 915 MHz). So you need a board with proper wiring for your selected frequency. Usually 433 MHz and 868/915 MHz boards cannot be swapped for this reason.
I’ve a TTGO LoRa32 v2.0, and once a LoRa packet is sent, the program hangs, outputting “WAITING” on USB serial monitor, and staying at that state forever.
Do you experience something similar?
I use:
const lmic_pinmap lmic_pins = {
.nss = 18,
.rxtx = LMIC_UNUSED_PIN,
.rst = 14,
.dio = {26, 33, 32},
Thanks for your help.
1 Like
If it should work for you, I would like to tell us about range! Thx!
- What USB serial monitor, from Arduino IDE?
- Where does “WAITING” come from?
The string is not in LMIC-Arduino or its ttn-abp.ini and ttn-otaa.ini examples nor have I seen it in Arduino and PlatformIO serial monitors. - Do you see anything at all on serial monitor?
- Do you output anything on the OLED display?
- Have you connected pin marked ‘11’ in the pinout diagram to gpio33 pin and pin marked ‘12’ to gpio32 pin? (See previous posts for explanation.)
yes, this one
I don’t know where the string is coming from. Here is what I see on serial monitor:
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:0x3fff0010,len:4
load:0x3fff0014,len:812
load:0x40078000,len:0
load:0x40078000,len:10164
entry 0x400789f8
Test (template version: 26Dec2016 generated: 12Jan2018 modified 12Jan2018)
BME280 detected!
temp Celcius:21.92 temp Fahrenheit:71.46 pressure:1032.81 altitude (meters):-163.67
3694 Sending.. Packet queued
3695 Waiting..
Yep, I output Temperature, humidity, pressure and altitude from the BME280 module, and it is refreshed properly until the LoRa packet is sent, and then, it freezes.
I don’t, but as there’s explanations for different boards, I got lost and thought I didn’t have to do so.
Which ones are these pins? I can see gpio32 and gpio33 on this diagram, but not pin marked “11” and “12” (or I don’t understand where I should look at)
Thanks for your help
That is the updated pinout diagram from @TKroenert where he removed the ‘11’ and ‘12’ because gpio11 and gpio12 appear not to be connected to these pins (but dio1 and dio2 are).
On the Heltec boards (on V2 at least) and TTGO V1 boards dio1 is connected to gpio33 (pin 33) and dio2 is connected to gpio32 (pin 32), as described in the topic start.
Here is the oiginal TTGO V2 pinout diagram where you can see pins 11 and 12.
For the TTGO V2 you will have to physically connect pin ‘11’ (dio1) to pin 33 (gpio33) and pin ‘12’ (dio2) to pin 32 (gpio32) yourself because they are not wired on-board. (You may wire them to other gpio ports when preferred but then you will have to adjust the pin settings in the software).
Please read above posts for more information.
I suggest to first start with the ttn-abp.ino example sketch from the LMIC-Arduino library, because that is the most basic and will make troubleshooting easier.
Then, when that works you can try the ttn-otaa.ino example sketch for over the air activation.
When you get both these sketches working then you know that the LoRaWAN stuff is working. From there you can start adding features/try other sketches, add temperature sensors etc.
(Note ABP and OTA nodes (‘end devices’) require different configuration settings, both in TTN console and software. See the TTN Console and remarks in the example sketches for more details.)
1 Like
OK that works now. I had some trouble with the BME280 library I was using (that made the sensor values crazy after a few measurements) so I changed it for the grove_BME280 one from Seeed. Everything is OK on this side for now.
A few questions:
-
Does somebody tried to optimise power consumption on the board, using a low power mode or so? And how? Currently, I’m only waiting to send the next packet, and would like to sleep instead for a given time.
-
Do you succeed in using cayenne LPP payload with the board? I tried to switch to that payload but somehow no packet is sent anymore and I got no debug output to investigate.
Thanks for your help!
ESP32 has three modes for deep sleep. The timer function which uses the ULP processor is most easy to implement;
//Serial.println("Bring ESP to sleep mode 2minutes");
/* 5e6 is 5x10^6 microseconds */
ESP.deepSleep(120e6);
some examples; espressif esp32 sleep examples
Aaron, over at Heltec, sent me the library and demo files that that they have:
This is a basic library for point-to-point LoRa communications.
This works with my two Heltec nodes operating one in transmit, and the other in receive. I still, however, have one board that will work with the LMIC library sending to TTN via OTAA, while the other does not.