Thank you Linar
Beware that SoftRF is not lorawan (So doesnt work with TTN). SoftRF only works with radio layer…
It is not 100% true statement. It would be more accurate to say: " it does not work with the TTN by default ".
Custom firmware builders may enable, setup and take advantage of optional “TTN Mapper” feature .
Sorry forma that! You are fully right, you can activate loraWAN by code😁
so i finally tried to get this thing running, hoping it would be easy with @DeuxVis TTNMapper port… well it likely is easy, but still being a noob i guess i’m missing some basic points.
it seems t-beam and software are running fine, i get reasonable output in the serial console and i can see traffic coming in on my TTN-gateway.
but - and this is something i can’t get my head wrapped round: the devaddr i see in the TTN-console is different from the one i set in config.h … is this normal with ABP activation? but since there’s a device with a different devaddr waiting for data in the TTN-app - i suspect this can’t work that way…
any idea what i’m doing wrong?
well, after creating a new device in the TTN app and using it’s devaddr i got an error compliling - so i realized it wasn’t the right format. after some digging found out i’d have to prefix the 0x
now i do get packets (22 bytes) with the correct devaddr in the gateway console - but not in the app itself, the device in there still shows a status of “never seen” …
check your device keys have not changed (NWKSKEY/APPSKEY) and copied to config.h, double check and then recompile - this is often the issue if the gateway is getting the packets but not the app
Finally got my tto t-beam working, had to tidy up code and had issues around the board type, in the end my platformio.ini looked like the following:-
[env:ttgobeam] platform = espressif32 board = ttgo-lora32-v1 framework = arduino upload_speed = 921600 monitor_speed = 115200 lib_deps = https://github.com/matthijskooijman/arduino-lmic https://github.com/mikalhart/TinyGPSPlus build_flags = -mfix-esp32-psram-cache-issue
No extra wiring needed, builtin LED was on pin 14 mind, not 21
has anybody got the GPS-module (I use the m8n version) into sleep-mode?
I think the power of the gps-module can’t be switched off with a gpio, right?
i have got TTGO T-beam (868) installed in my laptop with win7, but arduinio compiler doen’t work properly it says error at the end of compiling
expected ‘,’ or ‘;’ before ‘TinyGPSPlus’
TinyGPSPlus gps ;
I am having same problem with my TTGO -Tbeam , could you please share your coding to very with mine
On the Tbeam GPS is powered directly from 3.3V so it is not possible to switch it off with a GPIO (without cutting the trace)
I go into deep sleep mode on ESP32 but GPS never gets the position because it is rebooting every time
Also trying to reduce consumption in the gps moduel sending Special characters (0xB5, 0x62, 0x02, 0x41, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x4D, 0x) but also without sucess
Take a look to these links
Arduino Forum and characters to send
Neo6 power management
Keep trying, let you know
i am unable to upload TTN-Mapper coding into TTGO Tbeam , Arduino compiler results this error;
Using library SPI at version 1.0 in folder: C:\Users\dvfd\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.0\libraries\SPI
exit status 1
Error compiling for board Heltec_WIFI_LoRa_32.
Please some body help
I tried the TTGO beam and I did have the same problem as you guys. I was not able to put the GPS in sleep mode and the current was about 50 mA. I then desoldered the GPS module and the current went to 2.2 mA, ever so this is much better, for a low battery application this is still pretty high.
I also tried the TTGO LoRA V2.0 the current in sleep mode is 0.16 mA for this chip. (I did also remove a LED that didn’t turn off, I don’t know if this LED is connected to a GPIO).
Serial.println("go in to sleep"); esp_sleep_enable_timer_wakeup(TIME_TO_SLEEP * uS_TO_S_FACTOR); esp_deep_sleep_start();
Cool Jazzip0 , well done!
Did you try sending periodically data to TTN with GPS position and going into sleep mode to see how long does GPS take to have a fix position?
I copied the same code to my TTGO-Tbeam device and there is no compiler error , uploaded smoothly with my device addr and config.
but the device shows no connectivity on TTN console side.
@ jazzip0 - if you read this… excuses but I noticed that the system was thinking you’re a spammer.
and I can’t ‘undo’ this
Would it be an idea to use wifi to get location when the gps data is not valid? That way you could keep following your pet indoors.
The downsides here are that the unit is more sized toward a car or an ebike and that it seems to be rather power hungry on battery. Any progress on that? I’ve seen a sketch that delays sending when the position did not change, that should already make a difference.
@paulb : I’m not working on that project at the moment, but I definitely will integrate any improvements other people are publishing at some point.
If you want it faster, a great way to help is to submit a pull request on github.
After many investigations i have the solution to improve the poor level of transmit power on Lora TTGO version 1 at 868 Mhz ( I suppose it is version 1.) The lora TTGo like this :
There are 2 issues :
Software :LMIC library is not clear on this side : Check radio.c file, and go to SX1276 power definition ( about line 476 ) : add this at the end of configuration file: writeReg(RegPaConfig,0b01111111) : It suppose you have a hardware witout Paboost connected.
Hardware:Is low cost, interresting but poor RF design. I remove all the parts at he RF filter. I apply the Semtech ref design to changes 8 capacitors and inductors, and use Pa output without Paboost option
Measurement are performed with radio laboratory equipement in conducted condition : about ±0,1 dBm absolute accuracy. That’s my job.
Before : 2dBm : about 1,6 mW ( with LMIC modification describe above)
After : 14dBm : 25mW. ( with LMIC same modification describe above)
Conclusion : some issue around lora TTGO could be the result of wrong parts…Simply apply Semtech refdesign could solve the issue, without hard optimisation, without network analyser and PCB effect compensation.
I don’t check the receiver parts. May be some errors on design again…
You cannot have this kind of issues with RFM95 module.