LongMynd Receive Software

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