![]() Two weeks hard work. - Webserver config: - Allow freq to be configured down to 430.1000. Set to at minimum 430.150 if you use bandwith 250 kHz! - Added hint for wifi tcp kiss android config - platformio.ini: - less monolithic lib dependencies, because with heltec wireless tracker we have another radiolib and a TFT instead of OLED, no AXP chip, etc. - heltec section: need to have the many defineshere (two hand full are needed for TFT) - heltec wireless tracker: - long press (if WiFi off) sets the tracker to deep sleep (there's no real power-off due to the lack of an axp chip. But the current is very very low). See also notes at webserver config. - uses RadioLib SX126X - has no AXP chip, and the VEXT_CTRL pin only switches (both at the same time!), gps and tft. For power saving ("lora rx disabled" config setting), we can call radio.sleep(), and wake it up with radio.standby() - If you set gps to allow sleep, VEXT_CTRL turns also TFT. Be aware of it, it's not a bug but a hardware limitation. GPS sleep is for powersave. TFT off saves also power. That's what you should expect. On wakeup, tft is reinitialized. - Funny: If you do Serial.flush() and immediately call setCpuFrequencyMhz(adjust_cpuFreq_to), then USB chip is reset to a state before that what the esp32 driver inizializes. -> Serial.printf's don't work. This lead to Serial.print("CPU Freq ad"); Serial.flush(); setCpuFrequencyMhz(adjust_cpuFreq_to); // ..survived Serial.printf("justed to: %d MHz\r\n", adjust_cpuFreq_to); -> "CPU Freq ad" - and finito. => removed the flush() - TODO: bluetooth LE support. Unfortunately, the chip lacks support for classic bluetooth serial. If you need to connect aprsdroid to the device, look at the wifi tcp server description. - TTGO_T-Beam_LoRa_APRS.ino: - better platform dependend includes - I had a bad usb cable or switch with too less voltage which caused the ttgo to reboot -> Changes to minimum voltage for shutdown Disabled brownout detector (which was per default according to esp32 libs) WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0); Please check if this would be a problem of deep discharging your akku: #if defined(T_BEAM_V1_0) || defined(T_BEAM_V1_2) - if (InpVolts > 4.3) { + //if (InpVolts > 4.3) { // No, my usb hub suddenly only made 4.1V + if (InpVolts > 4.0) { I suppose no, because AXP does it's job at thosee devices - Needed to define BATTERY_PIN for every hardware - Renamed definition of LOW to TXLED_LOW - What is key_up, t_lock and time_delay? Wrong, it's for button control. -> Changed the names to button_key_up, button_t_lock and button_time_delay - LORA_MAX_MESSAGE_LEN is for SX127X (B_RF95 lib), because it includes the 4 bytes header. For the RadioLib buffer we need to reserver more space. - quite nice hack for reusing the display.xxx() routines for tft (class Emulated_SSD1306 which provides the needed functions) - New OLED_LINE_LEN_MAX instead of hardcoded value 21, because heltec TFT has in the normal font a width of 25. - RadioLib calls interrupt drivven signal_new_packet_received after a packet was receeived. - RadioLib special: Added definition for lora speeds / coding rate, like they have been addigned in the BG_RF95 lib - Pseudo-Sema-Locks: does not work 100%. Avoided endless loop by adding ESP.restart after 5min Also a delay of 1s in LoraSend() to mitigate lock problems when digipeating to the second of the both frequencies. - BG_RF95 sometimes causes crashes, esp. in waitPacketSent(). Introduced a delay. 100ms between sendAprs() and waitPacketSend() Changed calls to rf95.waitAvailableTimeout() to rf95.available() for stability reasons. - richonguzman has a good docu for power readings for non-AXP-chips. I use it for the heltec wireles tracker We may think about using it on T_BEAM_V0_7 and the rest. Problem: intensive testing needed, and the old T_BEAM_V0_7 devices became rare. - timer_once_a_second(): This is ok: if (!freeze_display) fillDisplayLine1(0); //update time & uptime But the following operations destroyed line3to5 for a displayed "((RX))" packet. -> Commented it out. No side effects observed-. - write2display(): now uses caching (calls write2display_cached()). Reason: TFT flickers when updates happen too often. On the other hand, caching on OLED is not possible because calling display.clearDisplay() is mandatory, else you get a pixel puzzle with old and new characters at each position. TFT has no display.display() and also nothing like clearLine. -> IF we write a line, we have to add (when using the normal font) blanks at the end of the text (up to position 25)-. Also, instead of OLED, TFT cannot brak long lins to the next; that's why we need to break the line ourself. The "next" lines we use in this case must not be cached. - fillDisplayLine1: Word "Up:" was behind the uptime value (caused by one of the commits of the last weeks). Fixed. - If own callsign is still N0CALL, disable lora_tx and set txPower to 0. - If during setup init lora chip or display fails, do not for(;;); , but sleep 5min and do ESP.restart(). Else you cannot land on the moon ;) TODO: check for correct initialization of SX126X chip - Removed tuplicate "Time used since start"-message - start of taskGPS moved to setup_phase2 section - If you double-click (or better "dit daah") the user button, manual beacon is triggered (like the behaviour at the end of the section). Needed by someone driving a car and cannot look at the display menu page number. - long press (if WiFi off) sets the heltec wireeless trackeer to deep sleep (nearly off - see description above). If wifi is off, press two times (first long-press starts webserver; second one does the shutdown). If tracker is not compiled with WIFI, long-press does a shutdown on heltec and a a reboot on other devices. TODO (and TEST!): check if other non-AXP-chip esp32 devices would instead also profit from a deep sleep - Tests before radio.readData() on SX126X devices are easier (no locking; no call comparing to rf95.available()), because flag_lora_packet_available is set. Changed general variable name packet_available to flag_lora_packet_available. - In part "((TX))", enforce a display update: fillDisplayLines3to5(1); Reason: tracker had his first gps fix and transmits - but the OLED showed the old position during TX; the sent packet hat the correct current position. - taskGPS: - support for heltec wireless tracker (Pin assignment and correct bitrate) - fix: - Serial.println(gpsDataBuffer); + Serial.print(gpsDataBuffer); - taskTNC: - if (serial_bt_client_is_connected) { + if (enable_bluetooth && serial_bt_client_is_connected) { - taskWebServer.cpp: deadlock protection, as in TTGO_T-Beam_LoRa_APRS.ino - data_embed: style.css and js.js had many blanks and comments which needed a quite large amount of disk space. A new script ../tools/remove_comment_from_code.py (which also can be used as a library) removes them, but leaves copyright comments intact. Feel free to use it in other projects. In summuary, many changes $ git diff|wc -l 2470 Signed-off-by: Thomas Osterried <dl9sau@darc.de> |
||
---|---|---|
.. | ||
README | ||
images.h | ||
preference_storage.h | ||
syslog_log.h | ||
taskGPS.h | ||
taskTNC.h | ||
taskWebServer.h | ||
wifi_clients.h |
README
This directory is intended for project header files. A header file is a file containing C declarations and macro definitions to be shared between several project source files. You request the use of a header file in your project source file (C, C++, etc) located in `src` folder by including it, with the C preprocessing directive `#include'. ```src/main.c #include "header.h" int main (void) { ... } ``` Including a header file produces the same results as copying the header file into each source file that needs it. Such copying would be time-consuming and error-prone. With a header file, the related declarations appear in only one place. If they need to be changed, they can be changed in one place, and programs that include the header file will automatically use the new version when next recompiled. The header file eliminates the labor of finding and changing all the copies as well as the risk that a failure to find one copy will result in inconsistencies within a program. In C, the usual convention is to give header files names that end with `.h'. It is most portable to use only letters, digits, dashes, and underscores in header file names, and at most one dot. Read more about using header files in official GCC documentation: * Include Syntax * Include Operation * Once-Only Headers * Computed Includes https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html