Big ESP32 + SX127x topic part 2

(Richjdavies) #451

Yikes… you go away for a month and come back and the thread has got huge.
I’ve got my TTGO V2’s (my TTGO V1’s weren’t cutting it) and now I’m completely lost about how to start on the code.
Sorry to be such a newbee, but could someone who’s got a TTGO-V2 working just summarise what to do?

  1. The pin-out part there’s so much back and forth I’m lost
  2. Is the Heltec lab a good starting place for TTGO’s too?
    I’m happy to write all this into a lab after, but completely lost right now :blush:
    Here’s what I wrote down after getting my TTGO V1 working…
    https://goo.gl/Vn4HWb
#452

How about doing what most others have to do: begin at the start of the thread, not at the bottom! :wink:
There is a very good start topic to help you get up and running quickly.

(Richjdavies) #453

:face_with_hand_over_mouth:oops - sorry, thought that hadn’t been edited since January (and the forum always puts me back at the end…). I see now it was updated in April my bad… FYI - from what I can tell this is all using the RFM in RAW mode using LMIC, not the approved Packetized mode… anyone got experience to do it the proper/legal way?

So - one other quick question - who’s got the lowest power usage on this board so far? Anyone getting the TTGO v2 down to the mythical reaches of µA?

(Arnas) #454

Hi again :frowning: I found out that the LoRaWAN data transfer connection is fixed and can only be calculated the theoretical transmission speed from LoRaWAN personal console> “application data.” Is it possible to calculate the data transfer speed between two Lora sx1276 ESP32? Can the speed be shown on the OLED screen?

(LoRaTracker) #455

On the transmitter, it would be easy enough, you know the packet size sent and you can time the start of the send and the completion.

(Bytebang) #456

I am using the “The Things Gateway” with an Aurel GP 868 antenna. Seems to work fine for my tests.

(Biermi) #457

Finally i have finished my new ttnmapper, It is based on the Heltec ESP32 Lora Board and a GY-GPS6MV2 (Neo 6M Chip). The case is self printed. Every 15 seconds it sends a signal with coordinates and hdop to TTN.

DSC06730

#458

Just curious, what is the UTP (ethernet) cable used for? (power? GPS?)
And the box on the right contains power or GPS?

(Biermi) #459

Yes the right box contains the GPS, i thought for my use cases (mapping by bike, car, train, foot) for that device it is a good solution to seperate both parts. The ethernet cable (CAT6e) is used for the GPS module. I have figured out that ethernet cable are a good solution because they are much more stable than normal DuPont cable. A DuPont cable can be easily removed by motion.

The power cell (18650) is under the Heltec Board and connected through the micro JTAG on the backside of the Heltec Board.

#460

New TTGO LoRa32 board spotted:

TTGO LoRa32 V2.1

1%20-%204
Observation: The basic board design is still the same but due to the SMA connector, under normal use the board will have to be rotated 180 degrees (otherwise the antenna points downwards) so the display will be rotated 180 degrees (most display libraries support that).
1%20-%202
1%20-%203

(Verkehrsrot) #461

Paxcounter software already has display flip mode integrated, usable for this board. Can be configured in paxcounter.conf

(Bsiege) #462

Maybe i still not understand the whole part of duty-cycle regulations and TTN fair-use policy. But for my sense i hardly believe that this can comply.

(Biermi) #463

Yes, you are right it does not really comply if it is 24/7 active. This node is only for mapping gateway coverage, so it runs only a few hours a day/week, for example on a walk arround the city.

(LoRaTracker) #464

If a packet is sent every 15 seconds, how does that impact on the legal duty cycle requirements ?

(Biermi) #465

I can only speak for Germany, because i live there and there is the mapper used. In Germany is the 1% rule, so only 1% of an hour can be used for duty cycle. 1% means that only 36 seconds can be used for transmitting data in 1 hour. The console shows 41ms airtime for sending the GPS data, so it can be send round about 878 packages in 1 hour to comply with the 1% rule. With a delay of 15 seconds between each sending, only 4 packages a minute and 240 per hour will be transmitted which is far away from the limit.

A Question for our other german guys here, the 1% rule of the Bundesnetzagentur is defined for 865,0–868,0 Mhz frequency band and also for 868,0–868,6 Mhz. The Lora devices using both frequency bands, so does it means that in case of equal using both frequency bands it have 2% an hour for sending? Or is it that one device have only 1% of an hour regardless of which frequency band is used?

(Jac Kersing) #466

It does not work that way. After you transmitted for 1% you need to wait 99% before the next transmission. So if you send 1 second you need to wait 99 seconds before you are allowed to transmit.
(Otherwise I could decide the 1% applies to a year and continuously transmit for 1 day)

(Bsiege) #467

41ms “estimated airtime”? This value seems to be still wrong. “Gateway Traffic” shows higher values and seems to be correct. Never seen lower than 51.5ms . How big is the payload?

(Biermi) #468

The payload size should be 9 byte, i have used the example from jpmeiers (https://github.com/jpmeijers/RN2483-Arduino-Library/blob/master/examples/TheThingsUno-GPSshield-TTN-Mapper-binary/TheThingsUno-GPSshield-TTN-Mapper-binary.ino#L178).

I don’t know if the console shows the correct value or not, i have not looked at the gateway console, the time was shown on the application site of the console.

(Richjdavies) #469

Wow. Fast model cycle. Haven’t even got my V2s up and running yet. I had suggested to Lily from LilyGo (appears to be the main distributor) to try to integrate a Lora antenna then it could.be certified, but no such luck so far.

Anyone got range or power measurements on any recent wild TTGO boards yet?

(Verkehrsrot) #470

DIO1+DIO2 of HPD13A LoRa Chip are now wired on the pcb to GPIOs of the ESP32, so no more external wiring is required for LMiC operation.

Besides that they changed the battery charging circuit. Now an IP5306 chip holds the charging logic, unfortunately still without digital connection to CPU for battery probing.

I already added a suitable hal-file to my paxcounter software, but couldn’t test it yet.