cyberman54
commented
6 years ago Done. (Hopefully people with existing loraconf.h will not complain...)
Closed trlafleur closed 6 years ago
cyberman54
commented
6 years ago Done. (Hopefully people with existing loraconf.h will not complain...)
trlafleur
commented
6 years ago I have your code running on a TTGO Ver 1 board
~~ /) ~~~~ /) ~~ _/) ~~ _/) ~~
Tom Lafleur
On Wed, Mar 21, 2018 at 2:51 PM, Verkehrsrot notifications@github.com wrote:
Done. (Hopefully people with existing loraconf.h will not complain...)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cyberman54/ESP32-Paxcounter/issues/6#issuecomment-375107944, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXCK1jZvTI1BHdeTVLJJlp3gLCM3Tkkks5tgstegaJpZM4S2Ao2 .
trlafleur
commented
6 years ago I did get error of DR_SF11 and 12 undefined
// help function to assign LoRa datarates to spreadfactor values void switch_lora (int sf, int tx) { if ( tx > 20 ) return; cfg.txpower = tx; switch (sf) { case 7: LMIC_setDrTxpow(DR_SF7,tx); cfg.lorasf=sf; break; case 8: LMIC_setDrTxpow(DR_SF8,tx); cfg.lorasf=sf; break; case 9: LMIC_setDrTxpow(DR_SF9,tx); cfg.lorasf=sf; break; case 10: LMIC_setDrTxpow(DR_SF10,tx); cfg.lorasf=sf; break; // case 11: LMIC_setDrTxpow(DR_SF11,tx); cfg.lorasf=sf; break; // case 12: LMIC_setDrTxpow(DR_SF12,tx); cfg.lorasf=sf; break; default: break; } }
~~ /) ~~~~ /) ~~ _/) ~~ _/) ~~
Tom Lafleur
On Wed, Mar 21, 2018 at 3:15 PM, Tom Lafleur lafleur@lafleur.us wrote:
I have your code running on a TTGO Ver 1 board
~~ /) ~~~~ /)
~~ _/) ~~ _/) ~~Tom Lafleur
On Wed, Mar 21, 2018 at 2:51 PM, Verkehrsrot notifications@github.com wrote:
Done. (Hopefully people with existing loraconf.h will not complain...)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cyberman54/ESP32-Paxcounter/issues/6#issuecomment-375107944, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXCK1jZvTI1BHdeTVLJJlp3gLCM3Tkkks5tgstegaJpZM4S2Ao2 .
cyberman54
commented
6 years ago try to add these lines in the top of rcommand.cpp:
Does it fix the problem?
cyberman54
commented
6 years ago fixed it in rcommand.cpp (probably was a side effect bug from recent code sanitization)
trlafleur
commented
6 years ago Your building a great framework for other TTN application... You may want to consider building a default framework code base, that allows application to be added with call backs...
As such, adding a time of day function with alarms that could trigger task would be very useful, as you have FreeRTOS, it might make it easy to add a library like this one below to build on... Device could make a request for time of day, and/or one could send time to the device(s) from time to time to keep RTC up-to-date using a linux time epic.
https://www.arduino.cc/en/Reference/RTC
adding deep sleep would also be a plus....
~~ /) ~~~~ /) ~~ _/) ~~ _/) ~~
Tom Lafleur
On Wed, Mar 21, 2018 at 3:45 PM, Verkehrsrot notifications@github.com wrote:
fixed it in rcommand.cpp (probably was a side effect bug from recent code sanitization)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cyberman54/ESP32-Paxcounter/issues/6#issuecomment-375120591, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXCK0NoAYPqgVXtBpChkmaNq3z9eVqxks5tgtgcgaJpZM4S2Ao2 .
cyberman54
commented
6 years ago This is an open source project, you are welcome to contribute with pull requests.
I'm not able to build a framework from it, due to missing time and knowledge.
--
Does the code now compile and run with TTGOv1?
cyberman54
commented
6 years ago RTC via TTN: it's not as easy to get exact time sync via LoRaWAN network. As far as i know github user FlorianLudwig has a solution on this, you may ask him.
cyberman54
commented
6 years ago Deep sleep would be an interesting option, but not for use case wifi scanner. Wifi scanning draws lots of power while running. The Heltec and TTGO boards are not suitable for deep sleep, because the peripherals cannot be shutdown on these boards, that means they draw power alle the time. Not sure yet what deep sleep capabilities the Pycom LoPy boards have.
trlafleur
commented
6 years ago I let you code run all night, what interesting is that I see more join request that data sends?? very odd...
~~ /) ~~~~ /) ~~ _/) ~~ _/) ~~
Tom Lafleur
On Thu, Mar 22, 2018 at 3:06 AM, Verkehrsrot notifications@github.com wrote:
Deep sleep would be an interesting option, but not for use case wifi scanner. Wifi scanning draws lots of power while running. The Heltec and TTGO boards are not suitable for deep sleep, because the peripherals cannot be shutdown on these boards, that means they draw power alle the time. Not sure yet what deep sleep capabilities the Pycom LoPy boards have.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cyberman54/ESP32-Paxcounter/issues/6#issuecomment-375242806, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXCK2uGh1tGFt6Vr5k20EHEKG4ckjFiks5tg3eZgaJpZM4S2Ao2 .
cyberman54
commented
6 years ago That looks like the device makes resets and then tries again to join the network. After a reset payload "0000" is sent.
Multiple joins may be caused by tweak LoRa radio coverage, or can be caused by bad RF-path on the ESP32 module. Since you seem to use a TTGOv1 you may want to take a look in TheThingsNetwork forum, multiple issues with bad RF performance were reported for TTGOv1. E.g. sometimes the pigtail cables were broken, or wrong antennas (433 MHz) were delivered.
Multiple resets can be caused intentionally by code, the code has a max LoRa retry threshold value which can be configured in main.h
Resets may also be caused by insufficient power supply.
The used LMiC code is robust and tested, it will sure not cause this behaviour.
trlafleur
commented
6 years ago I have been using LMiC code for over a year and have over 220 nodes deployed...
I agree with all of your points, but the GW ia 10 ft away, same TTGO module, antenna, power supply has been running for over two week solid with my base code....
So just wanted to point this out to you...
~~ /) ~~~~ /) ~~ _/) ~~ _/) ~~
Tom Lafleur
On Thu, Mar 22, 2018 at 11:04 AM, Verkehrsrot notifications@github.com wrote:
That looks like the device makes resets and then tries again to join the network. After a reset payload "0000" is sent.
Multiple joins may be caused by to weak LoRa radio coverage, or can be caused by bad RF-path on the ESP32 module. Since you seem to use a TTGOv1 you may want to take a look in TheThingsNetwork forum, multiple issues with bad RF performance were reported for TTGOv1. E.g. sometimes the pigtail cables were broken, or wrong antennas (433 MHz) were delivered.
Multiple resets can be caused intentionally by code, the code has a max LoRa retry threshold value which can be configured in main.h
Resets may also be caused by insufficient power supply.
The used LMiC code is robust and tested, it will sure not cause this behaviour.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cyberman54/ESP32-Paxcounter/issues/6#issuecomment-375403980, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXCK1LzBaCGCOvvW12Ro4yE9jQNqB9xks5tg-e2gaJpZM4S2Ao2 .
cyberman54
commented
6 years ago Wifi & BLE may need much more power than your base code on the TTGO.
My TTGOv2 board crashes when run on battery at the point in code, when Wifi & BLE are activated. The ESP32 throws a brownout reset.
Check the logs on serial console in verbose mode at the point, when the module resets. If it throws a brownout error, the problem is likely a power supply problem.
I can't guarantee that LMIC in RTOS task is running stable. I found reports on the net that say it does not. But i did long time tests over serveral weeks with 5 Heltec boards and this code, and they did not crash.
trlafleur
commented
6 years ago Sorry for doing this in email.... I’m not on my computer...
This maybe an issue...
In main.c you do a: #ifdef DEVEUI To see if DEVEUI is defined in you config file... A quick test of this by defining DEVEUI, shows it’s not working by sending the generated DEVEUI.
No time to investigate this today....
void os_getDevEui (u1_t* buf) {
memcpy(buf, DEVEUI, 8); RevBytes(buf, 8); // TTN requires it in LSB First order, so we swap bytes
gen_lora_deveui(buf);
}
On Thu, Mar 22, 2018 at 12:35 PM Verkehrsrot notifications@github.com wrote:
Wifi & BLE may need much more power than your base code on the TTGO.
My TTGOv2 board crashes when run on battery at the point in code, when Wifi & BLE are activated. The ESP32 throws a brownout reset.
Check the logs on serial console in verbose mode at the point, when the module resets. If it throws a brownout error, the problem is likely a power supply problem.
I can't guarantee that LMIC in RTOS task is running stable. I found reports on the net that say it does not. But i did long time tests over serveral weeks with 5 Heltec boards and this code, and they did not crash.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cyberman54/ESP32-Paxcounter/issues/6#issuecomment-375431376, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXCKxiFe_htirClB3Hf6U7T9OKf8Gjfks5tg_0OgaJpZM4S2Ao2 .
--
~~ /) ~~~~ /) ~~ _/) ~~ _/) ~~
Tom Lafleur
cyberman54
commented
6 years ago please find a solution for this a make a pull request. I'm beginner im C / C++.Am 22.03.2018 22:31 schrieb Tom Lafleur notifications@github.com:Sorry for doing this in email.... I’m not on my computer...
This maybe an issue...
In main.c you do a: #ifdef DEVEUI To see if DEVEUI is defined in you config file... A quick test of this by defining DEVEUI, shows it’s not working by sending the generated DEVEUI.
No time to investigate this today....
void os_getDevEui (u1_t* buf) {
memcpy(buf, DEVEUI, 8); RevBytes(buf, 8); // TTN requires it in LSB First order, so we swap bytes
gen_lora_deveui(buf);
}
On Thu, Mar 22, 2018 at 12:35 PM Verkehrsrot notifications@github.com wrote:
Wifi & BLE may need much more power than your base code on the TTGO.
My TTGOv2 board crashes when run on battery at the point in code, when Wifi & BLE are activated. The ESP32 throws a brownout reset.
Check the logs on serial console in verbose mode at the point, when the module resets. If it throws a brownout error, the problem is likely a power supply problem.
I can't guarantee that LMIC in RTOS task is running stable. I found reports on the net that say it does not. But i did long time tests over serveral weeks with 5 Heltec boards and this code, and they did not crash.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cyberman54/ESP32-Paxcounter/issues/6#issuecomment-375431376, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXCKxiFe_htirClB3Hf6U7T9OKf8Gjfks5tg_0OgaJpZM4S2Ao2 .
--
~~ /) ~~~~ /) ~~ _/) ~~ _/) ~~
Tom Lafleur
—You are receiving this because you modified the open/close state.Reply to this email directly, view it on GitHub, or mute the thread.
cyberman54
commented
6 years ago fixed with 1.2.33
In main.c you do a: #ifdef DEVEUI To see if DEVEUI is defined in you config file... A quick test of this by defining DEVEUI, shows it’s not working by sending the generated DEVEUI.
You need to do it for both.. DEVEUI and APPEUI