kopia lustrzana https://github.com/SP8EBC/ParaTNC
515da4bfa4 | ||
---|---|---|
.settings | ||
Debug | ||
hardware | ||
include | ||
ldscripts | ||
src | ||
system | ||
.cproject | ||
.gitignore | ||
.project | ||
HARDWARE-README | ||
README | ||
README-pl | ||
WIRING | ||
asm | ||
skalowania.ods |
README
ParaTNC version DE00, September 10th 2019 ----------------------------------------- 1. INTRODUCTION ParaTNC is a software (hardware design coming) intended to work on STM32F100RB microcontroler and cheap STM32VLDISCOVERY evaluation board as an multi function APRS controler. It supports key elements of what good APRS device should have: -> Two directional KISS TNC (no init strings required). -> WIDE1-1 digipeater, with an option to limit digipeating only to SSIDs 7, 8 and 9. -> Weather station with support for various meteo sensors like: DS18B20 for temperature, MS5611 for pressure, LaCrosse TX20 for wind and DHT22 for humidity. -> Extensive telemetry with an information about the count of receved, transmitted and digipeated frames plus status of weather sensors. -> Support for VE.Direct serial protocol used in Victron PV charging controllers. The data about currents and voltages in the PV system are transmitted using APRS telemetry. 2. LICENSING ParaTNC software and hardware are licensed under terms included to the source code in 'LICENSE' file 3. SUPPORTED FEATURES OD VE.Direct PROTOCOL Most of Victron devices have a support both for binary and text serial protocol. By default the text procol (VE.Direct) is always enabled and a device will send from its own telegrams each couple of seconds. The communication via VE.Direct is avaliable through dedicated socket on the charging controller which is just 3.3V TTL levels UART, so no external ICs is required to connect the PV controller to an evaluation board. In the MPPT series the comm socket is located on the bottom side of the chargin controller below the fuse holder. Exact pinout of the VE.Direct comm socket is as follows, assuming that terminal screws are facing down: -> Ground -> TX, data from host to the PV controller -> RX, data from PV controller to the host The controller sends a lot of different data which cannot be completely transmitted through APRS network due to radioprotocol limitations. Only these parameters are transmitted: -> Battery Current (charging as positive, discharging as negative) in third channel of telemetry. -> Battery Voltage as fourth telemetry channel. -> PV cell Voltage as fifth telemetry channel. -> Charging Controller status (like current charging mode) and minimum/maximum battery current in last 10 minutes. -> Error Codes if any (short circuit, overheat, overvoltage on PV or battery input) 4. TELEMETRY If the VE.Direct protocol suppot is disabled the ParaTNC uses telemetry packets to send internal statistics and general information about communication with sensors. Telemetry works in 10 minutes cycle, which means that packets are sent every 10 minutes and they represents a state for the time between one and another. Analog channels: 1st Channel: Number of packets received in 10 minutes. 2nd Channel: Number of packets transmitted in 10 minutes (digi-ed + generated internally by the controller) 3rd Channel: Number of digipeated packets in 10 minutes. 4th Channel: Number of packet received from Host by KISS protocol 5th Channel: Optional temperature from Dalls One Wire sensor. Digital Channels: DS_QF_FULL - Quality Factor for One Wire temperature sensor is FULL DS_QF_DEGRAD - Quality Factor for One Wire temperature sensor is DEGRADATED DS_QF_NAVBLE - Quality Factor for One Wire temperature sensor is NOT AVALIABLE MS_QF_NAVBLE - Quality Factor for MS5611 pressure sensor ins NOT AVALIABLE DHT_QF_NAVBLE - Quality Factor for DHT22 humidity & temperature is NOT AVALIABLE TX20_SLEW - LaCrosse TX20 anemometer driver dropped at least one measuremenet due to excesive slew rate. Explantion of Quality Factors: Each measuremenets signal is kept along with the Quality Factor which represents the sensor condition and value validity. If the QF is set to FULL it means that no communication problems happened between one telemetry cycle and another DEGRADATED is set if at least once the communication problem happened (CRC calculation fail, timeout etc). NOT AVALIABLE is set if all communication atempts failed and no valid measuremenet value is avaliable. By default each Quality Factor is set to NOT AVALIABLE after the telemetry packets are sent. The TX20 anemometer driver has a Slew Rate Limiter which keeps out all 'spikes' in values mostly due to RF interference. if the difference between two consecutive measuremenets excedes hardcoded limit (9m/s) the software drops the value. 5. CONFIGURATION At this point ParaTNC is delivered in form of source code which needs to be manually compiled by the user. Most options are configured by #define in './include/station_config.h' and then hard-coded by the C preprocessor during compilation. An example file consist a lot of comments which explains what is what, but generally an user can choose there which mode should be enabled: -> KISS TNC -> KISS TNC + DIGI -> KISS TNC + DIGI + METEO -> VICTRON + DIGI + METEO -> VICTRON + DIGI As You see there is no option to use a KISS modem and the VE.Direct protocol in the same time as the software support only one UART in the micro. The KISS modem runs on default speed of 9600 bps. Telemetry is enabled by default and it will trasmit channels values each 10 minutes and full channel descriptions each 70 minutes. 6. TOOLCHAIN AND COMPILATION To build ParaTNC software 'GNU ARM Embedded Toolchain' is required. This set contains gcc-arm-none-eabi compiler, gdb debugger, linker, HEX generator and set of libraries. ParaTNC is developed in Xubuntu 16.04LTS using 2016q-3 version. It shoud work fine in any newer version of the toolchain. The easies way to get everything installed and configured is to use a packet manager, like aptitude in ubuntu/debian. Information about the toolchain, installation instructions etc can be found here: https://launchpad.net/gcc-arm-embedded https://developer.arm.com/open-source/gnu-toolchain/gnu-rm https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa When everything is installed the reporistory can be cloned to local harddrive by using a command 'git clone https://github.com/sp8ebc/ParaTNC' The example config file is named 'station_config_example.h' and should be edited and then renamed to 'station_config.h'. When everything is configured it is a time to go to 'Debug' directory and invoke command 'make' there. The source should be automatically compiled and new hex file 'ParaTNC.hex' should appear in the same directory. Finished building target: ParaTNC.elf Invoking: Cross ARM GNU Create Flash Image arm-none-eabi-objcopy -O ihex "ParaTNC.elf" "ParaTNC.hex" Finished building: ParaTNC.hex Invoking: Cross ARM GNU Print Size arm-none-eabi-size --format=berkeley "ParaTNC.elf" text data bss dec hex filename 50542 576 5544 56662 dd56 ParaTNC.elf Finished building: ParaTNC.siz 22:29:38 Build Finished (took 13s.231ms) 7. LOADING THE HEX FILE INTO STM32VLDISCOVERY BOARD The STM32VLDISCOVERY board has an ST-Link/V1 programmer-debugger on board which can be used to load a HEX file. This ST-Link appears normally as a mass storage device which makes in unusable to be used by HEX loadin software in Linux (as the device will be 'blocked' by the mass-storage driver). To workaround this problem, a configuration of modprobe daemon should be changed to ignore the ST-Link and not load any driver for it. This is done by invoking a command: 'sudo echo "options usb-storage quirks=483:3744:i" >> /etc/modprobe.d/stlink_v1.conf' What will create a new file called 'stlink_v1.conf' in modprobe directory. After the system reboot changes should be applied and the programmer should be free to go. The kernel log should looks somehow like this below [90639.895886] usb 2-1.1: new full-speed USB device number 13 using ehci-pci [90639.990288] usb 2-1.1: New USB device found, idVendor=0483, idProduct=3744 [90639.990294] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [90639.990296] usb 2-1.1: Product: STM32 STLink [90639.990298] usb 2-1.1: Manufacturer: STMicroelectronics [90639.990300] usb 2-1.1: SerialNumber: Qÿr\xffffff86RV%X\xffffffc2\xffffff87 [90639.990796] usb-storage 2-1.1:1.0: USB Mass Storage device detected [90639.992973] usb-storage 2-1.1:1.0: device ignored The next step is to install texane-stlink which supports the ST-Link/V1 programmer and can be used to read an write the flash memory. Installation is quite straight forward 'git clone git://github.com/texane/stlink.git' 'cd stlink.git' 'make' 'cd build/Relase' 'sudo cp st-* /usr/bin' At the end the HEX file can be loaded into the microcontroler by typing a command 'sudo st-flash --format ihex write /dev/sr0 ParaTNC.hex'