Big ESP32 + SX127x topic part 2

End Devices (Nodes)
24

I mean that DIO1 and DIO2 are not connected to GPIO11 and GPIO12, but they are connected to the pins of the pinheader labeled 11 and 12 which are not connected to the GPIO11 and GPIO12 of the ESP.

TL;DR: Connect 11/12 with 32/33 and Bob’s your uncle!

The pinmapping from aliexpress… and that I can toggle GPIO32/33 with digitalWrite() (checked with a multimeter) but I don’t see any changes on the pins DIO1/DIO2 of the LoRa-module.

But I still don’t get it running…
Yesterday I connected 11/12 with 32/33 and for the first time I get a few more lines on the uart:

387386994: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
387449783: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
387451087: EV_TXCOMPLETE (includes waiting for RX windows)
387452201: engineUpdate, opmode=0x900
389327200: engineUpdate, opmode=0x908
389327245: TXMODE, freq=868300000, len=26, SF=7, BW=125, CR=4/5, IH=0
Packet queued

I followed this blogpost My Chinese ESP32 + SX1276 board + DHT11 connected to The Things Network – #1 – ICT en Onderwijs BLOG to setup arduino with lmic library.
I’m using his code: GitHub - PiAir/esp32-sx1276: Code voorbeelden voor het ESP32 + SX1276 board.

I’m not running my own gateway, so I took a walk to a place with better reception ( http://ttnmapper.org/ )… came back, hit F5 and the only thing I see is the framecounter :neutral_face:
ttn

25

Weird that GPIO11 and GPIO12 are not available at pins labeled 11 and 12 (meaning GPIO11 and GPIO12).
That implies that the board has two GPIO ports LESS available and that DIO1 and DIO2 will have to be manually connected to GPIO ports on other pins when needed. I can’t think of any good reason for that.

If the pins labelled 11 and 12 are not GPIO11 and GPIO12 then be prepared for more inconsistencies.

The simplest configuration for testing ESP32+LoRa is download the LMIC-Arduino library (the one mentioned in topic start) and use its ttn-abp.ino example (without adding any additional features). This will send a small string as payload for testing. If that works you can start trying other adventures (OTAA, your own messages etc.).

“and the only thing I see is the framecounter”

No messages showing up in the data tab?

26

Another issue with “Heltec” Lora32 board:

I’m currently running two boards in 24/7 test. Both pcb’s look fully identical from outside view. Both were purchased from same seller on Amazon in one delivery and came in packaging labeled DIYnik.

Both boards connect to my MatchX TTN gateway, which is ~30m away outdoor. Both boards run identical test code, using LMiC 1.5 arduino-2 with OTAA and SF7.

On the gateway logs one board shows up with RSSI values -60…-70, which is, i think, an expectable level.

The other board shows up with RRSI values -90 … -110, which is surely too weak for the short distance.

I checked both antennas and pigtail cables with a multimeter, no shortage.

Any ideas, what may going wrong here?
How could i figure out the root cause? What to measure?

Gateway logs for board no. 1:

  "frequency": 868.3,
  "modulation": "LORA",
  "data_rate": "SF7BW125",
  "coding_rate": "4/5",
  "channel": 1,
  "rssi": -91,
  "snr": 7.5,
  "rf_chain": 1

Gateway logs for board no. 2:

  "frequency": 868.5,
  "modulation": "LORA",
  "data_rate": "SF7BW125",
  "coding_rate": "4/5",
  "channel": 2,
  "rssi": -71,
  "snr": 6,
  "rf_chain": 1

IMG_20180125_202138

27

Have you already measured with each board in the exact same position, with the same pigtail and the same antenna (and for both pigtails/antennas)?

Not sure how big the difference but I would also test with the antennas in upright position (for best/most reliable results), assuming the gateway antenna is also in upright position.

28
29

I changed the antennas already, what made no difference.
You’re right, i should change the pigtails, too, and i will keep boards in exact same positions.

But i don’t think that 20cm difference in position (see picture) can cause such a high difference in RSSI value over a distance of only 30m on SF7.

30

Issues with Rev.0 of the ESP32 and differences between Rev.0 and Rev.1 could possibly play a role for problems experienced in this topic.
But the tweet you are referring to and the linked readme do not indicate what “was the problem all te time” exactly means and what Rev.1 has fixed (and if it is fixable with Rev.0 if you know its bugs).

See: HOW TO CHECK THE REVISION LEVEL OF YOUR ESP32

31

I changed the pigtails. Makes no difference. Still one board has 30 RSSI difference compared to the other.

I checked all pigtails on shortage and passage with Ohm meter. All okay.

32

yes, a bit unclear. but the direction seems to be the same

33

Why double post? (see HOW TO CHECK THE REVISION LEVEL OF YOUR ESP32 above).

34

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
35

@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
36

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
37

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.)

62

Hi,

Could you please advise whether it will be possible to use Heltec esp32 to read 433 Mhz Oregon sensors data?

thank you

63

ESP32 revision information can also be gathered at runtime using this piece of code

64

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.

lora-modules-1m-range

5 Likes
65

Why double post? (see HOW TO CHECK THE REVISION LEVEL OF YOUR ESP32 above).

66

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.

67

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