ATHENA
Athena is a Software project intended to develop a software developers kit for the HPSDR radio system. The objective of the project is to provide a multi-platform code basis that will help programmers write client programs using the output of the HPSDR boards. Project goals include:
- - Document all the communications protocols and the Library Application Protocol Interface (API)
- - Explore the development of RTP [1] and RTSP [2] protocols for the sending of data over ethernet.
- - Development of IO compatible server code to communicate with the HPSDR hardware and communicate with client programs with UDP/TCP commands.
- - Develop a set of operating specific server code that maintains IO compatibility.
- - Potentially develop libraries of functions to help programmers easily access the server.
This project will be run as a moderated open source software project. Code contributions will be evaluated as to the degree it contributes to the over all goals of the project and whether there are undesired interactions with existing code.
Athena is the Greek goddess of home industry including spinning, weaving and carpentry. She is also the goddess of wisdom and known to be very clever, She is also the goddess of war. This is a good name for the server program that is the main connection between many parts of a HPSDR system.
Project leader is Dave Larsen, KV0S
Team members include:
- John Melton, G0ORX/N6LYT
- Bill Tracey, KD5TFD
- Dave McQuate, WA8YWQ
- Jeremy McDermond, NH6Z
Ideas, comments and suggestions are welcome.
Contents
ghpsdr3 Communication Protocols 2010-08-07
Here is the document of the current ghpsdr3 communication protocols.
ghpsdr3 communication protocols 2010-08-07
This document is also available on the ghpsdr3 svn under 'doc' directory
--KV0S, Dave 14:56, 7 August 2010 (UTC)
Draft HPSDR Object Rule Set
Based on the discussion on the list server in August 2010, This is an attempt to capture the many of the ideas and create a set of program rule. Design ideas are the programs have discovery and capability reporting. Radio system objects are peers but the the dominate information flow is from hardware to a User interface with some information moving the in reverse direction. This set of rule becomes more important as we move to the ethernet connections but is relevent to USB connections and object to object communications.
Information components include:
- 1. Connection informations
- This is the discovery of Radio system components currently in the users environment. This include both hardware connections and other programs using part of all the radio capabilities.
- 2. Object capabilities
- This is information about the capabilities of the object.
- Example:
- - Radio Model x
- - Sampling Base Frequency 14.125MHz
- - Sampling Rate 96kHz
- - I and Q are 24 bit signed integers
- - available on x.x.x.x port y
- - Data format
- - Commands available
- This is information about the capabilities of the object.
- 3. Object current status
- This is information about the current status of the object.
Possible structure container could be JSON
--KV0S, Dave 18:04, 6 August 2010 (UTC)
Design Ideas
The following is a list of ideas that have been suggested on either the Teamspeak session or the HPSDR reflector.
- - The user should be able a common set of HPSDR function to interface with the hardware.
- - Definitions of the UDP/TCP packets structure and allowable command variation to the structure.
- Command set to be accepted.
- Can packet length and structure be varied by commands?
- Logging and peripheral control by TCP? Command structure (CAT?, other)
- - Can we design the structure to accommodate both low latency applications and remote base applications?
- Options that a user could use to favor one or the other.
- - Code documentation formats to follow?
- Doxygen, other?
Links
- SVN --- Subversion repository of HPSDR code.
