search

softerhardware / Hermes-Lite2

A second generation low-cost amateur HF software defined radio transceiver.
http://www.hermeslite.com
230 stars 78 forks source link

Issues with the Hermes-Lite2 addtions to the openHPSDR USB frames over IP or Protocol 1 #115

Closed matthew-wolf-n4mtt closed 5 years ago

matthew-wolf-n4mtt commented 5 years ago

There is a new version of the OpenHPSDR USB frames over IP protocol. The document for version 1.60 was paced on Github in the past month. The the Hermes-Lite2 "C0 Type" for "RX 8 NCO Frequency" over laps with the new "C0 Type" for "2ND Alex, Firmware Envelope Gain" that was added in version 1.60 of the official protocol. Also in the protocol document the "C0 Types" are defined as 7 bit numbers NOT 6 bit numbers. I am adding the Hermes-Lite2 to my Wireshark plugin "openhpsdr-u". The plug-in uses 7 bit numbers for the "C0 Types" below are the 7 bit numbers for the Hermes-Lite2 addtional "C0 Types"

// Hermes-Lite2 Addtions // Defined as 6 bit numbers. The stanard defines the C0 types as 7 bit numbers. // This dissector is writen using 7 bit numbers for the C0 types. // - 1st number 6 bits - 6:1 // - 2nd number 7 bits - 7:1 - 1st number left shifed once for MOX. // 0x12 0x24 HL2 RX 8 NCO Frequency (Over Lap with 0x24 2ND Alex, Firmware Envelope Gain) // 0x13 0x26 HL2 RX 9 NCO Frequency // 0x14 0x28 HL2 10 NCO Frequency // 0x15 0x2A HL2 RX 11 NCO Frequency // 0x16 0x2C HL2 RX 12 NCO Frequency // 0x2B 0x56 HL2 Predistortion // 0x3B 0x76 AD9866 SPI // 0x3C 0x78 I2C1 // 0x3D 0x7A I2C2 // 0x3f 0x7E Extended Write Data

softerhardware commented 5 years ago

Hi Matthew,

The Hermes-Lite only attempts to be compatible with openHPSDR protocol 1 for core use. As you have discovered, we have additional extensions that Quisk and SparkSDR use. For example, the 6 bits for C0 is because we have added commands that require a response by using the extra bit. This is documented on the wiki: https://github.com/softerhardware/Hermes-Lite2/wiki/Protocol

I'd be interested in hearing if you think any of the extensions would conflict with core openhpsdr software use.

73,

Steve kf7o

matthew-wolf-n4mtt commented 5 years ago

The major issue is that my plug-in is not correct .I is treating the 7 bit C0 type a a 8 bit number. This will be corrected in the next release. The OpenHPSDR protocol 1 documents are not written in a way that lists the length of the fields.

There should be no issue with Hermes-Lite2 additional 6 bit C0. When they are treated as 7 bit numbers the 7th bit is a zero.

The conflict with C0 18 (0x12) is due to the newest version of the protocol. I let you know if I discover any more conflicts.

Corrected list of "C0 Types": // The "C0 Types" are 7 bit numbers. // Before version 0.4.0 they were in-correctly treated as 8 bit numbers. // 0 0x00 Configuration // 1 0x01 TX NCO Frequency // 2 0x02 RX 1 NCO Frequency // 3 0x03 RX 2 NCO Frequency // 4 0x04 RX 3 NCO Frequency // 5 0x05 RX 4 NCO Frequency // 6 0x06 RX 5 NCO Frequency // 7 0x07 RX 6 NCO Frequency // 8 0x08 RX 7 NCO Frequency // 9 0x09 TX Drive, Anntena Presect, VNA // 10 0x0A RX Pre-amp, IF Gain, PureSignal, Open Drain, TTL, 20db/ADC1 Attn // 11 0x0B ADC[123] Attn, CW Config // 12 0x0C Additional Mercury 1 // 13 0x0D Additional Mercury 2 // 14 0x0E ADC RX Assignment // 15 0x0F CW Configuration 2 // 16 0x10 CW Configuration 3 // 17 0x11 PWM Configuration // 18 0x12 2ND Alex, Firmware Envelope Gain

// Hermes-Lite2 Addtions // 18 0x12 HL2 RX 8 NCO Frequency (Conflict with core 0x12 - per 1.60) // 19 0x13 HL2 RX 9 NCO Frequency // 20 0x14 HL2 10 NCO Frequency // 21 0x15 HL2 RX 11 NCO Frequency // 22 0x16 HL2 RX 12 NCO Frequency // 43 0x2B HL2 Predistortion // 59 0x3B AD9866 SPI // 60 0x3C I2C1 // 61 0x3D I2C2 // 63 0x3F Extended Write Data