Wow, thank you for the link on Fair Access policy. I had no idea of the restrictions. After reading all that i feel like some kind of reckless CB radio guy , with no idea. As a licenced radio ham, I should have considered there may have been restrictions. My Approach was of the Packet radio days, And so my approach also considered none encrypted and beacon that broadcast my GPS location in plain txt. Now that i have read the restrictions i can see even my usage needs to be reduced and to repeat foreign packets is wasting my allowable usage. My lora reciever picks up very few foreign packets. So i feel some logic regarding fair use should take into account that the user may be in an area of few or no other devices. So there is a lot of capacity. It would make some sense to have an adaptive usage based on spare capacity in the area. Also adaptive transmitter strength depending on density of other devices. Just a thought… But again thank you for pointing me to the policy, as i don’t want to be that annoying person spoiling it for everyone else.
One thing is duty cycle limitation (1%), this is by law and there is no easy way to tell whether you are in an area with “few or no other devices”, and also for much time the situation will remain the same.
A different thing is the Fair Access Policy, which is regulating the use of a shared and free, yet owned and paid by someone, resource like the network server, for which the logic you feel may not be so logic (other providers limit free accounts in different and stricter ways). If you pay for a TTI account, FAP will not be an issue. However, there is a specific thread about this.
your welcome (and please stick to the topic start)
But as @UdLoRa points out, you are using getting free use of all the back end TTN network. Even though your perhaps in a quiet area, your using the same amount of that resouce and support as a user in a busy area.
tried again and it compiled??? strange but working now
Try changing every instance of TinyGPSPlus to gps
Instead of TinyGPSPlus(…) change it to gps(…) and give that a try
There are several T-Beam Arduino sketches on github that claim to work with TTN. Some clearly never did and never will. For example, never initializing the SPI interface, wrong ESP32 pin mappings for the LoRa SX1276 pins, ‘radio not supported’ error messages, … Often the understanding of which ESP32 pin is connected to the BLUE LED is not correct. This is sad.
This problem is lack of code control. The sketches cannot be used to program a T-Beam as claimed in the various github T-Beam repositories. The main culprit is the lmic library. The issue is which lmic library, from what github, with whatever github revision purported to function. The Arduino maker community often fails to comprehend a .ino sketch that references a library needs that library code to be able to reproduce the working sketch. Since the libraries are not included with the sketch, we are left to search for candidate lmic libraries. There are many, each with a history of revisions in github repositories.
So as far as I can see, the T-Beam hardware is perfectly capable of connecting to the TTN gateways if the .ino sketch code ever were to match up with the correct lmic library. Until that happens, the T-Beam will never connect to TTN. It is called code control. None exists for the T-Beam.
Now, starting from scratch, I have been able to blink the LED, read the push button, create a Bluetooth NMEA sentence GPS, and exchanged data between a pair of T-Beams over the LoRa radio. The next step is to port the IBM lmic library code to the ESP32. Yes, this exactly what the many lmic repositories on github claim to have done, but do any of them work with an identifiable .ino sketch? We need code control. We need to be able to recreate a working system from a given code base.
So far, the T-Beam has been a waste of time for me, but has provided a fantastic journey learning about ESP32, LoRa, and LoRaWAN. Unfortunately, it has not worked out for TTN.
You are right about the whole code control thing. However the TTGO works with the ESP32-PAXCounter codebase which works with TTN, and the ttnmapper integration. I have programmed the TTGO with it using Visual Studio Code.with the PlatformIO module. The (compatible) LMIC library is provided.
It works very well.
I agree with the code control problem. MarkD has 3 TTGO T-Beams that connect to TTN, work with TTN Mapper and continue to work well. He has shared his code with us.
I’ve edited the same code to work with the TTGO V1 without OLED and TTGO V2 with OLED.