Difference between revisions of "LongMynd Receive Software"
(Created page with "The LongMynd Receive softawre...") |
|||
Line 1: | Line 1: | ||
− | + | This page provides additional information on the LongMynd Receive software that would not fit in CQ-TV | |
+ | |||
+ | Status Messages and the Test Harness | ||
+ | The status messages are designed to be machine readable. The test harness simply dumps these to the screen using the program fake_read. The important message is the State (ID=1) which will tell the user what the software is doing and what it has found. Here is the specification of the status message and what they mean. | ||
+ | The status fifo is filled with status information as and when it becomes available. The format of the status information is: | ||
+ | |||
+ | $n,m<cr> | ||
+ | |||
+ | Where: | ||
+ | n = identifier integer of Status message | ||
+ | m = integer value associated with this status message | ||
+ | |||
+ | And the values of n and m are defined as: | ||
+ | ID Meaning Value and Units | ||
+ | ================================================================ | ||
+ | 1 State 0: initialising | ||
+ | 1: searching | ||
+ | 2: found headers | ||
+ | 3: locked on a DVB-S signal | ||
+ | 4: locked on a DVB-S2 signal | ||
+ | 2 LNA Gain On devices that have LNA Amplifiers this represents the two gain | ||
+ | settings of the LNAs | ||
+ | Sent as n, where n = (lna_gain<<5) | lna_vgo | ||
+ | Though not actually linear, n can be usefully treated as a single | ||
+ | byte representing the gain of the amplifier | ||
+ | 3 Puncture Rate During a search this is the puncture rate that is being trialled | ||
+ | When locked this is the puncture rate detected in the stream | ||
+ | Sent as a single value, n, where the puncture rate is n/(n+1) | ||
+ | 4 I Symbol Power Measure of the current power being seen in the I symbols | ||
+ | 5 Q Symbol Power Measure of the current power being seen in the Q symbols | ||
+ | 6 Carrier Frequency During a search this is the carrier frequency being trialled | ||
+ | When locked this is the Carrier Frequency detected in the stream | ||
+ | Sent in KHz | ||
+ | 7 I Constellation Single signed byte representing the voltage of a sampled I point | ||
+ | 8 Q Constellation Single signed byte representing the voltage of a sampled Q point | ||
+ | 9 Symbol Rate During a search this is the symbol rate being trialled | ||
+ | When locked this is the symbol rate detected in the stream | ||
+ | 10 Viterbi Error Rate Viterbi correction rate as a percentage * 100 | ||
+ | 11 BER Bit Error Rate as a Percentage * 100 | ||
+ | |||
+ | Software Structure | ||
+ | Where possible the code structure reflects the structure of the hardware but it has been written so as to abstract the various hardware modules as far as possible so that future NIM modules might be more easily integrated in. | ||
+ | Communications to the FTDI USB interface are all handled via libusb, this in turn uses an FTDI protocol to control the outputs of the FTDI interface board which in turn control the I2C interfaces to the NIM. | ||
+ | I2C access to the NIM demodulator (STV0910) are done directly. Accesses to the LNA (STVVGLNA) and the tuner (STV6102) are done via an I2C repeater in the demodulator. This allows the LNAs and Tuners to be isolated from noisy I2C traffic to/from the demodulator. | ||
+ | The code is all written in standard C for portability and, where possible, does not rely on distribution specific features. | ||
+ | Here is a very brief overview of the files in the code distribution and what they do. | ||
+ | |||
+ | Makefile The usual makefile. | ||
+ | errors.h Just the definitions of all the error codes that the system can report. | ||
+ | fake_read.c Test harness program to read and (crudely) display status messages. | ||
+ | This is intended to illustrate how to get the data out of the status FIFO. | ||
+ | fifo.c The Linux FIFO handlers for TS and Status FIFO init, read and write. | ||
+ | fifo.h | ||
+ | ftdi.c Code associated with the FTDI USB interface. | ||
+ | ftdi.h | ||
+ | ftdi_usb.c The USB interface handlers for talking to the FTDI chips. | ||
+ | ftdi_usb.h | ||
+ | go.sh Test Harness script to get longmynd working stand alone. | ||
+ | longmynd.1 Local manual page definitions. | ||
+ | main.c Handles the command line processing, status reporting, module | ||
+ | initialisation and the state machine for the demodulator. | ||
+ | nim.c Handles communications to/from the NIM itself. This is where the | ||
+ | repeater is turned on or off and the register accesses can happen. | ||
+ | nim.h | ||
+ | stv0910.c Demodulator handlers including init, status reporting, clock setting etc. | ||
+ | stv0910.h | ||
+ | stv0910_regs.h Definitions of the demodulator registers and bit fields. | ||
+ | stv0910_regs_init.h Because of the huge number of registers involved almost all of the | ||
+ | initialisation is done by writing initial states to every writeable register. | ||
+ | This means quite a bit of the functionality of the demodulator setup is | ||
+ | defined at initialisation. | ||
+ | stv0910_utils.c Here we abstract out the register writes and reads to the demodulator. | ||
+ | Because of the large number of registers it was found to be useful to | ||
+ | create a shadow set of registers to speed up non-volatile register reads. | ||
+ | stv0910_utils.h | ||
+ | stv6120.c The Tuner handlers including clock setting, init and PLL locking. | ||
+ | stv6120.h | ||
+ | stv6120_regs.h Definitions of all the Tuner registers and bitfields. | ||
+ | stv6120_utils.c Abstraction of the Tuner register read and write code. | ||
+ | stv6120_utils.h | ||
+ | stvvglna.c The LNA handlers (for newer NIMs with the LNAs). | ||
+ | stvvglna.h | ||
+ | stvvglna_regs.h Definitions of the LNA registers and bit fields. | ||
+ | stvvglna_utils.c Abstraction of the LNA read and Write routines. | ||
+ | stvvglna_utils.h | ||
+ | udp.c The UDP protocol handlers for TS over UDP. | ||
+ | udp.h |
Revision as of 17:24, 20 September 2019
This page provides additional information on the LongMynd Receive software that would not fit in CQ-TV
Status Messages and the Test Harness The status messages are designed to be machine readable. The test harness simply dumps these to the screen using the program fake_read. The important message is the State (ID=1) which will tell the user what the software is doing and what it has found. Here is the specification of the status message and what they mean. The status fifo is filled with status information as and when it becomes available. The format of the status information is:
$n,m<cr>
Where:
n = identifier integer of Status message m = integer value associated with this status message
And the values of n and m are defined as: ID Meaning Value and Units
====================================================
1 State 0: initialising 1: searching 2: found headers 3: locked on a DVB-S signal 4: locked on a DVB-S2 signal 2 LNA Gain On devices that have LNA Amplifiers this represents the two gain settings of the LNAs Sent as n, where n = (lna_gain<<5) | lna_vgo Though not actually linear, n can be usefully treated as a single byte representing the gain of the amplifier 3 Puncture Rate During a search this is the puncture rate that is being trialled When locked this is the puncture rate detected in the stream Sent as a single value, n, where the puncture rate is n/(n+1) 4 I Symbol Power Measure of the current power being seen in the I symbols 5 Q Symbol Power Measure of the current power being seen in the Q symbols 6 Carrier Frequency During a search this is the carrier frequency being trialled When locked this is the Carrier Frequency detected in the stream Sent in KHz 7 I Constellation Single signed byte representing the voltage of a sampled I point 8 Q Constellation Single signed byte representing the voltage of a sampled Q point 9 Symbol Rate During a search this is the symbol rate being trialled When locked this is the symbol rate detected in the stream 10 Viterbi Error Rate Viterbi correction rate as a percentage * 100 11 BER Bit Error Rate as a Percentage * 100
Software Structure Where possible the code structure reflects the structure of the hardware but it has been written so as to abstract the various hardware modules as far as possible so that future NIM modules might be more easily integrated in. Communications to the FTDI USB interface are all handled via libusb, this in turn uses an FTDI protocol to control the outputs of the FTDI interface board which in turn control the I2C interfaces to the NIM. I2C access to the NIM demodulator (STV0910) are done directly. Accesses to the LNA (STVVGLNA) and the tuner (STV6102) are done via an I2C repeater in the demodulator. This allows the LNAs and Tuners to be isolated from noisy I2C traffic to/from the demodulator. The code is all written in standard C for portability and, where possible, does not rely on distribution specific features. Here is a very brief overview of the files in the code distribution and what they do.
Makefile The usual makefile. errors.h Just the definitions of all the error codes that the system can report. fake_read.c Test harness program to read and (crudely) display status messages. This is intended to illustrate how to get the data out of the status FIFO. fifo.c The Linux FIFO handlers for TS and Status FIFO init, read and write. fifo.h ftdi.c Code associated with the FTDI USB interface. ftdi.h ftdi_usb.c The USB interface handlers for talking to the FTDI chips. ftdi_usb.h go.sh Test Harness script to get longmynd working stand alone. longmynd.1 Local manual page definitions. main.c Handles the command line processing, status reporting, module initialisation and the state machine for the demodulator. nim.c Handles communications to/from the NIM itself. This is where the repeater is turned on or off and the register accesses can happen. nim.h stv0910.c Demodulator handlers including init, status reporting, clock setting etc. stv0910.h stv0910_regs.h Definitions of the demodulator registers and bit fields. stv0910_regs_init.h Because of the huge number of registers involved almost all of the initialisation is done by writing initial states to every writeable register. This means quite a bit of the functionality of the demodulator setup is defined at initialisation. stv0910_utils.c Here we abstract out the register writes and reads to the demodulator. Because of the large number of registers it was found to be useful to create a shadow set of registers to speed up non-volatile register reads. stv0910_utils.h stv6120.c The Tuner handlers including clock setting, init and PLL locking. stv6120.h stv6120_regs.h Definitions of all the Tuner registers and bitfields. stv6120_utils.c Abstraction of the Tuner register read and write code. stv6120_utils.h stvvglna.c The LNA handlers (for newer NIMs with the LNAs). stvvglna.h stvvglna_regs.h Definitions of the LNA registers and bit fields. stvvglna_utils.c Abstraction of the LNA read and Write routines. stvvglna_utils.h udp.c The UDP protocol handlers for TS over UDP. udp.h