kopia lustrzana https://github.com/SP8EBC/ParaTNC
273 wiersze
16 KiB
Plaintext
273 wiersze
16 KiB
Plaintext
ParaTNC version DF03, June 25th 2020
|
||
-----------------------------------------
|
||
|
||
// Please look into 'doc' directory for more documentation and user manuals
|
||
|
||
1. INTRODUCTION
|
||
ParaTNC is a hardware and a software which offers the functionality of multi function APRS controler.
|
||
The software itself can also run on cheap STM32VLDISCOVERY board with slightly reduced functionality, but
|
||
with costs about 10..12 euro this gives the cheapest possible standalone APRS controller.
|
||
|
||
ParaAPRS 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. Full list od supported devices in point 5.
|
||
-> 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.
|
||
-> Support for UMB Binary porotocol as a mater.
|
||
|
||
ParaAPRS can be used as a standalone weather station controller w/o using the radio transmission. The sw
|
||
by default sends the measuremenets values
|
||
|
||
2. ParaAPRS HARDWARE
|
||
The ParaTNC software can run on STM32VLDISCOVERY board but it really shows it full potential od it's own
|
||
dedicated hardware. This not only rub out all bodge wires required with prototype board. It gives
|
||
few features which are hardly not possible without dedicated PCB
|
||
a) Two different grounds separated one from the another (HW Revision A and B)
|
||
-> Controller
|
||
-> DB9 connector used to interface with a radio and Wind & Temperature sensor
|
||
aa) ONLY IN HW REVISION C: Three different grounds separated one from the another
|
||
-> Controller
|
||
-> DB9 connector used to interface with a radio
|
||
-> Wind and temperature sensor including RS485 bus
|
||
b) Isolated DC-DC coverter to supply sensors with an option to connect another external power supply itself
|
||
c) A relay used as a watchdog to reset wind & temperature sensor in case that no communication will be received.
|
||
d) RS232 serial port avaliable on Cisco style RJ45 connector.
|
||
e) RS485 serial port interchable with RS232 (with HW Revision A) or working fully independly (HW Revision B)
|
||
f) PCB designed to fit into Mikrotik RB411/RB711 enclosure.
|
||
|
||
ParaTNC PCB could be manufactured used a set of generber files locates in ./hardware/ directory a long with schematics and
|
||
layout renders (top and bottom layer).
|
||
|
||
3. CURRENT OPEN POINTS AND ISSUES RELATED TO HW & SW
|
||
As usually every design has some flaws, less or more important. In case of ParaTNC they can be divided into two
|
||
parts, separately for software and hardware. Firstly in case of software an end user should USE ALWAYS THE SOURCE CODE
|
||
WITH THE NEWEST TAG marked as non-beta (like DE07). ParaTNC repository is used for daily development, so the last commit
|
||
can even sometimes don't compile at all, or consist some major bugs.
|
||
|
||
Hardware workarounds in HW Revision A:
|
||
-> Missing resistor in series with base of transistor T2. External 1k must be added in series with TX line
|
||
-> Foortprint location of R7 (RX_LVL) and R8 (TX_LVL) helipots are 'not optimal'. If 'normal' pots are to be used the vertical
|
||
version must be chosen as flat one won't fit due to neighbouring components location.
|
||
-> J1 power-in jack has reversed polarity (negative center)
|
||
-> The chineese manufacturer dropped the TX20 anemometer from the production which means that a supoprt to it
|
||
became a little bit obsoloete for new installations. Support for Davis 6410 anemometer or any another with
|
||
pulse output for windspeed and potentiometer (resistance output) for direction is ongoing and should be
|
||
avaliable in HW-Revision B and further SW releases.
|
||
|
||
Hardware workarounds in HW Revision B:
|
||
-> Few missing traces in micro supply. Few bodge wired needs to be added. Please look at hardware-revision-b-errata.jpg in 'hardware'
|
||
|
||
4. LICENSING
|
||
ParaTNC software and hardware are licensed under terms included to the source code in 'LICENSE' file
|
||
|
||
5. SUPPORTED METEO SENSORS
|
||
a) Wind sensors:
|
||
- TX20 (not in manufacturing anymore)
|
||
- Davis 6410 or any another analogue anemometer with resisntance as a direction output and impulses as a windspeed
|
||
WARNING: Not avaliable in Hardware Revision A due to lack of circuitry. Fully working only in HW-Rev C
|
||
- Lufft V200A/Ventus or any other UMB compatible device.
|
||
b) Pressure Sensors:
|
||
- MS5611
|
||
- Bosh BMP280
|
||
- Any UMB protocol compatible device
|
||
c) Temperature sensors:
|
||
- Dallas One wire DS18B20
|
||
- Any UMB protocol compatible device
|
||
d) Humidity Sensors:
|
||
- DHT22
|
||
- Bosh BMP280
|
||
|
||
|
||
6. 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 charging 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)
|
||
|
||
7. 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
|
||
WIND_QF_DEGR - LaCrosse TX20 anemometer driver dropped at least one measuremenet due to excesive slew rate.
|
||
WIND_QF_NAVB -
|
||
|
||
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.
|
||
|
||
8. 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:
|
||
|
||
Hardware Revision A:
|
||
-> KISS TNC
|
||
-> KISS TNC + DIGI
|
||
-> KISS TNC + DIGI + METEO
|
||
-> VICTRON + DIGI + METEO
|
||
-> VICTRON + DIGI
|
||
|
||
Hardware Revision B & C:
|
||
-> KISS TNC
|
||
-> KISS TNC + DIGI
|
||
-> KISS TNC + DIGI + METEO
|
||
-> KISS TNC + VICTRON + DIGI + METEO
|
||
-> KISS TNC + VICTRON + DIGI
|
||
-> KISS TNC + UMB-MASTER + DIGI + METEO
|
||
|
||
In Hardware Revision A there is no option to use a KISS modem and the VE.Direct protocol in the same time as only
|
||
one UART in the micro is used and handled by software. In hardware revisions B and C two UARTS are used and handled by
|
||
the software. The KISS modem is always enabled and avaliable on RJ45 Cisco style jack.
|
||
|
||
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.
|
||
|
||
|
||
9. TOOLCHAIN
|
||
To build the 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 and 20.04LTS
|
||
using toolchain in version 2018q-2. Please take note that You have to use 64-bit version of the operation system
|
||
as the 32-bit variant of the toolchain is not avaliable.
|
||
|
||
Self conatined TAR.BZ2 archive with all required tools can be found here:
|
||
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
|
||
in 'What's new in 7-2018-q2-update' section pulled down from the list located in the middle of this site.
|
||
Alternatively You can use this link: http://pogoda.cc/d/gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2
|
||
|
||
After download the content of this archive has to be uncompressed into: /usr/local/bin/gcc-arm-none-eabi-7-2018-q2-update/
|
||
so the structure should looks like this
|
||
|
||
mateusz@mateusz-ThinkCentre-M720q:/usr/local/bin/gcc-arm-none-eabi-7-2018-q2-update$ ls -la
|
||
total 24
|
||
drwxrwxr-x 6 mateusz mateusz 4096 paź 10 08:35 .
|
||
drwxr-xr-x 7 root root 4096 paź 10 18:06 ..
|
||
drwxr-xr-x 6 mateusz mateusz 4096 cze 22 2018 arm-none-eabi
|
||
drwxr-xr-x 2 mateusz mateusz 4096 cze 22 2018 bin
|
||
drwxr-xr-x 3 mateusz mateusz 4096 cze 22 2018 lib
|
||
drwxr-xr-x 4 mateusz mateusz 4096 cze 22 2018 share
|
||
mateusz@mateusz-ThinkCentre-M720q:/usr/local/bin/gcc-arm-none-eabi-7-2018-q2-update$
|
||
|
||
Both a makefile and an Eclipse project are configured to look for toolchain in this directory. In some cases to perform
|
||
a debugging in Elipse You will have to install libncurses5 library which is required to start GDB. To check if
|
||
this is a case try to start the debugger manually by issuing such command in the prompt
|
||
|
||
'/usr/local/bin/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-gdb --version'
|
||
|
||
If such result will be printed in the console, libncurses5 must be installed, prefferably using system package
|
||
manager like aptitude in Debian/Ubuntu
|
||
|
||
'libraries: libncurses.so.5: cannot open shared object file: No such file or directory'
|
||
|
||
To start debugging session in Eclipse you must create new 'GDB OpenOCD Debugging' configuration and set paths
|
||
to OpenOCD and GDB in 'Debugger' tab. OpenOCD usually sits in '/usr/bin/openocd', the path to GDB is shown in
|
||
the paragraph before. Remember to set 'Config Options:' to tell the OpenOCD what JTAG adapter/debugger is used
|
||
in Your setup. If You're using ST-Link/V2 paste '-f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg'
|
||
|
||
10. DOWNLOADING THE SOURCE CODE AND COMPILING IT
|
||
|
||
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. Please do not use Release configuration!! It is screwed and produces an
|
||
application which doesn't works exactly as it should because of optimalization configuration.
|
||
|
||
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)
|
||
|
||
11. LOADING THE HEX FILE USING THE SERIAL BOOTLOADER
|
||
If You don't have a JTAG programmer/debugger or You just not want to or can't use it for any reason, You can choose
|
||
Internal Serial Bootloader provided by STMicroelectronics. It's code is stored in mask ROM within microcontroler
|
||
and can be used anytime, and in scope of ParaTNC it practically cannot be disabled or locked. Please remember that
|
||
this option is avaliable only if You're using ParaTNC PCB as STM32VLDISCOVERY board doesn't have TTL-RS232 converter.
|
||
|
||
To use serial bootloader You need:
|
||
- RJ45 to DB9 Cisco style RS232 cable
|
||
- FlashLoader Demonstrator software provided by STMicroelectronics for free
|
||
|
||
The required software can be downloaded from this link: https://www.st.com/en/development-tools/flasher-stm32.html
|
||
It is advised to read the user manual for this tool before proceding further. To jump to the bootloader You shall
|
||
disconect power to ParaTNC, then use something to short the jumper located at the left of JTAG connector (top-left
|
||
corner of PCB) and with jumper shorted reconnect the power supply. If procedure success You shall NOT hear
|
||
relay clicking and LEDs blinking for a short while. After the power supply is connected and micro stays in bootloader
|
||
you can disconnect the jumper and start the FlashLoader software to download the HEX file to micro. After process is done
|
||
you should do a cold reset without jumper shorter.
|
||
|
||
12. 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'
|