Controlling the HF-150

[SiriusHardware]

A recent HF-150 keypad interface repair thread started by Steve G4WCS veered off into a conversation about how to computer control the receiver by sending signals to it via the keypad input connector. At the same time, another forum member appeared with another faulty HF-150 so I have started this thread to continue on with the discussion about controlling these receivers.

Jez provided some extremely valuable scope shots of some typical frequency-change code sent by an original Lowe IF-150 interface and I find that I can decode them by eye now.

Key to understanding these is the keycode table from the HF150 'Technical Supplement' - I've come across this before because I used the info to get my homebrew HF-150 keypad going, but it turns out that the same 5-bit codes are used to represent the same characters in the data bursts from the IF-150 computer interface as well. See the table, image #1.

The first thing you may well ask is why not just send 00000 for "0", 00001 for "1", 00010 for "2", and so on? I think this goes back to the fact that the first version of the HF150 keypad used an off the shelf remote control transmitter chip which had this character table baked into its hardware. Having been forced to accommodate that code table for communications from the keypad the decision was obviously made to keep the same code -> character table for the IF-150's communications with the HF-150 as well.

Image #2 is one which jez posted in the other thread, it shows the first (white) and second (yellow) data bursts of six to change the frequency to 5489KHz.

We see that the format of every data burst is the same, there are three 'header' pulses whose leading edges are separated by time T2, then there is a fixed interval T3 between the leading edge of the third header pulse and the leading edge of the first of the six data pulses. I say six, but these six pulses altogether only represent 5 bits, because it is the interval between their leading edges which determines the bit values. T4 (Longer) signifies a binary '1', T5 (shorter) signifies a binary '0'. Because of this, the overall length of a data burst varies with the data value being transmitted. A data burst with the value '00000' will be the shortest, a data burst with the value '11111' will be the longest.

We then have another interval of T3 between the leading edge of the last data pulse and the leading edge of the final pulse.

If I decode the whole of the six-burst packet which jez posted as pairs (1+2, 1+3, 1+4, 1+5, 1+6) the transmitted characters come out as "05489#", "#" being 'enter'. I haven't confirmed it yet but it looks as though the first five characters are the frequency to enter including any necessary leading zeros, terminated with the sixth character, 'Enter'. I have yet to look at the 8-character frequency setting message which can be used to set the frequency with a finer degree of resolution.

Before I go any further I would appreciate it if jez would be so kind as to measure the following time intervals as accurately as possible - not urgent, jez, but it would be great if you would be able to do this some time.

T1 (The width of a single pulse, from leading edge to trailing edge)

T2 (The interval between the leading edge of one header pulse and the leading edge of the next header pulse)

T3 (The interval between the leading edge of the last header pulse and the leading edge of the first data pulse). I believe the interval between the leading edge of the sixth data pulse and the leading edge of the final pulse is also T3.

T4 (The interval between the leading edges of the pulses defining a logic '1')

T5 (The interval between the leading edges of the pulses defining a logic '0')

T6 (not shown on the image). The interval between the leading edge of the final pulse in one data burst and the leading edge of the first header pulse in the next data burst.

[jez_145]

and the results are.........


T1 (The width of a single pulse, from leading edge to trailing edge) (0.305 mS)

T2 (The interval between the leading edge of one header pulse and the leading edge of
the next header pulse) (3.040 mS)

T3 (The interval between the leading edge of the last header pulse and the leading edge
of the first data pulse). I believe the interval between the leading edge of the sixth data
pulse and the leading edge of the final pulse is also T3. (6.080 mS)

T4 (The interval between the leading edges of the pulses defining a logic '1') (3.020 mS)

T5 (The interval between the leading edges of the pulses defining a logic '0') (2.040 mS)

T6 The interval between the leading edge of the final pulse in
one data burst and the leading edge of the first header pulse in the next data burst.
(40.00 mS)


Also attached zip containing above summary and scope cursor screen shots for each measurement.

Good work Sirius !

I'm thinking of applications for this already. Deluxe scanning keypad anyone ?

Jez

[SiriusHardware]

Very quick work, thanks jez. I had a suspicion that T2 and T4 were probably the same and they are really close, so I suspect that the same timing is used for both.

I looked at your original capture of a complete 8-burst packet (FRQ_17.PNG) for a fine tuned frequency but unfortunately some of the pulses are blobbed together in the image and can't be 'read' in the way that I read the more detailed one in my previous post.

If you get a chance could you recapture the last four of the eight bursts for the same 'long' frequency in sufficiently high resolution to be 'read' so we can see exactly how the fine tune information is sent. The info in the keypad table appears to say that the fine frequency data is an 8-bit value, which is strange when all of the other packets are 5-bit.

[jez_145]

No prob.

For completeness I've attached screenshots for all 8 of the data bursts for the FRQ 28734.324 example so you can animate your way through them.

Yes, it's strange that they used an alternative strategy for the "high resolution" frequency entry. Kind of blows my original idea of dividing the user entered frequency (with or without a decimal point) by 8Hz (the minimum resolution of the HF-150's tuning) and just outputting a tuning offset number.

Are you ok with the other examples for mode change and memory management - whilst I've got the test rig set up ?

Jez

[SiriusHardware]

You've already gone above and beyond the call of duty today, thanks for all your time and patience... will look at the captures in your last post when I have time later (at work just now).

I think the ones for mode change and recall from memory are quite straightfoward as both of those are also supported by the keypad, or at least the V2 version of the keypad. I should be able to get the mode-select facility (hold down CANCEL while pressing a numeric key) working on my homebrew PIC based HF-150 keypad at some point as well.

[SiriusHardware]

All right, I couldn't resist having a look... so the first six bursts are a standard 5-digit + 'enter' frequency change, and then the 7th burst is 11111 ('Set fine tune') and the 8th burst has a non standard nine data bit delimiting pulses representing 8 bits in the intervals between them. Thanks for anticipating that I would want to know the interval between the 6th and 7th bursts, incidentally.

The 8-bit 'fine set' value which somehow represents the post-decimal '.324' portion of the long frequency 28734.324 is 01010010 which translates to 52 hex or 82 decimal.

Bearing in mind that the actual tuning resolution is in steps of 8Hz, so any frequency entered is converted to the nearest 8Hz step, I find that:-

(82 decimal x 4) = 328, which is one of the nearest 8Hz steps to .324. It could also have been rounded down to 320, but was rounded up to 328 instead.

Of course I could just be choosing the formula which conveniently gives me the answer I want, so the next step would be to capture several more eighth bursts with just the post-decimal portion of the frequency changed to other values. If the same multiply-the-fine-value-by 4 dodge works for other post decimal values then you won't have been far off the mark when you anticipated that something like this sort of calculation might be used, but only for defining the sub-1KHz portion of the frequency.

[jez_145]

Originally Posted by SiriusHardware

All right, I couldn't resist having a look...

I knew that would happen - I could see it coming !

Ok, I'm taking requests for post-decimal seventh and eighth bit bursts (I really must get out more).

Anything in particular ?

.1
.12
.123
.234
.345



Jez

[SiriusHardware]

Four or five semi random values between .001 and .999 would be good, and maybe at least one of them an exact multiple of 8 and two others which are +1 and -1 from an exact multiple of 8, any others to be random, within the from-to range specified.

How about offsets of....
.192
.623
.833
.053
.986

[jez_145]

Ok, results attached with a couple of extra examples.

Observations

1) Burst 7 appears to be constant as in "the next burst is going to be the fractional part".

2) A mantissa <= .003 results in a standard, integer frequency, six burst. An eight burst is only output when the mantissa >= 0.004

Jez

[SiriusHardware]

Thanks Jez -

See if you (or anyone else) can reconcile these burst-8 data values with their associated frequency offsets.

Scope 		Fraction of KHz 	Burst-8		As Hex	As Decimal
Capture					Data value
Image 					in binary

8B_01.png	FRQ 0.192<c/r>		00110001 	31	49
8B_02.png	FRQ 0.623<c/r> 		10011111 	9F 	159
8B_03.png	FRQ 0.833<c/r> 		11010101 	D5 	213
8B_04.png	FRQ 0.053<c/r> 		00001101 	0D 	13
8B_05.png	FRQ 0.986<c/r> 		11111100 	FC 	252
8B_06.png	FRQ 0.123<c/r> 		00011111 	1F 	31
8B_07.png	FRQ 0.345<c/r> 		01011000 	58 	88
8B_08.png	FRQ 0.678<c/r> 		10101101 	AD 	173
8B_09.png	FRQ 0.910<c/r> 		11101000 	E8 	232

It is possible I may have misread the binary values of one or two of these from the scope captures, although I went through them twice.

[John KC0G]

Hello Jez and Sirius

You are doing some very good work here. I am the owner of the LoweHFReceivers group at groups.io. We have archives of the two previous Yahoo groups, but I do not remember any discussion on the serial interfaces at this level of detail.

I can explain 7 of the 8 bits in the 8th burst. First of all, the Lowe HF-150 does not tune in 8 (= 1000 / 125) Hz steps, but in 1000 / 128 = 7.8125 Hz steps. The decimal value = INT(last three digits * 0.128). Going down the list
0.192 24.57
0.623 79.74
0.833 106.62
0.053 6.78
0.986 126.20
0.123 15.74
0.345 44.16
0.678 86.78
0.910 116.48
If you look at the first seven digits reading left to right, you will see that they are the binary values of the above decimals.

That leaves the right hand or 8th binary digit. It does not look like a parity bit. It does seem to match whether the decimal value after the decimal point is greater than (= 1) or less than (= 0) 0.5

HTH and 73

John KC0G / M0KCY

Edited the decimal values to add the values after the decimal point. Changed interpretation of the 8th binary digit.

[SiriusHardware]

Same table again, but with the addition of the nearest 8Hz step to the fraction of a KHz entered. What we need to do is work out how the decimal number in the 'As Decimal' number column represents the frequency offset in the 'nearest 8Hz step' column.

Fraction of KHz 	Burst-8		As Hex	As Decimal 	Nearest 8Hz step
			Data value
			in binary

FRQ 0.192<c/r>		00110001 	31	49		192			
FRQ 0.623<c/r> 		10011111 	9F 	159		624
FRQ 0.833<c/r> 		11010101 	D5 	213		832
FRQ 0.053<c/r> 		00001101 	0D 	13		056
FRQ 0.986<c/r> 		11111100 	FC 	252		984
FRQ 0.123<c/r> 		00011111 	1F 	31		120		
FRQ 0.345<c/r> 		01011000 	58 	88		344		
FRQ 0.678<c/r> 		10101101 	AD 	173		176
FRQ 0.910<c/r> 		11101000 	E8 	232		912

Edit: just caught John's post - reading it now.

[SiriusHardware]

That information about the increments being 7.8125 is rather critical John, thanks. I don't know where I got 8Hz from. I've just caught your further edits to post #11 so I am still playing catch-up.

[John KC0G]

Sorry. We are trading posts here. I just edited my post of 4.20pm. It might provide an explanation.

The 8Hz step is a good first order approximation in a discussion of tuning rates. We need more accuracy here.

[SiriusHardware]

Well, armed with the new info regarding the step size I have now generated a new table.

In column one, all possible 7-bit values of bits 7-1 of the eighth burst, as decimal.

In column two, the frequency offset generated by multiplying the value in the first column by 7.8125 Hz.

In the third column are the occasional offset values requested by jez when he was capturing that info for us.

Along with those in the fourth column is the difference in Hz between the requested frequency and the selected frequency - always less than 7.8125Hz, and for the frequencies tried at least, always on the low side of the requested frequency.

Bits	Times by	Frequency	Difference 
7-1	7.8125Hz	Offset (Hz)	(Hz) between
of			requested	requested
eighth			Through		Offset and
burst			IF-150		Actual offset
as
decimal	


0	0
1 	7.8125
2 	15.625
3 	23.4375
4 	31.25
5 	39.0625
6 	46.875		053		-6.125
7 	54.6875
8 	62.5
9 	70.3125
10 	78.125
11 	85.9375
12 	93.75
13 	101.5625
14 	109.375
15 	117.1875	123		-5.8125
16 	125.0
17 	132.8125
18 	140.625
19 	148.4375
20 	156.25
21 	164.0625
22 	171.875
23 	179.6875
24 	187.5		192		-4.5	
25 	195.3125
26 	203.125
27 	210.9375
28 	218.75
29 	226.5625
30 	234.375
31 	242.1875
32 	250.0
33 	257.8125
34 	265.625
35 	273.4375
36 	281.25
37 	289.0625
38 	296.875
39 	304.6875
40 	312.5
41 	320.3125
42 	328.125
43 	335.9375
44 	343.75		345		-1.25
45 	351.5625
46 	359.375
47 	367.1875
48 	375.0
49 	382.8125
50 	390.625
51 	398.4375
52 	406.25
53 	414.0625
54 	421.875
55 	429.6875
56 	437.5
57 	445.3125
58 	453.125
59 	460.9375
60 	468.75
61 	476.5625
62 	484.375
63 	492.1875
64 	500.0
65 	507.8125
66 	515.625
67 	523.4375
68 	531.25
69 	539.0625
70 	546.875
71 	554.6875
72 	562.5
73 	570.3125
74 	578.125
75 	585.9375
76 	593.75
77 	601.5625
78 	609.375
79 	617.1875	623		-5.8125
80 	625.0
81 	632.8125
82 	640.625
83 	648.4375
84 	656.25
85 	664.0625
86 	671.875		678		-6.125	
87 	679.6875
88 	687.5
89 	695.3125
90 	703.125
91 	710.9375
92 	718.75
93 	726.5625
94 	734.375
95 	742.1875
96 	750.0
97 	757.8125
98 	765.625
99 	773.4375
100 	781.25
101 	789.0625
102 	796.875
103 	804.6875
104 	812.5
105 	820.3125
106 	828.125
107 	835.9375
108 	843.75
109 	851.5625
110 	859.375
111 	867.1875
112 	875.0
113 	882.8125
114 	890.625
115 	898.4375
116 	906.25		910		-3.75
117 	914.0625
118 	921.875
119 	929.6875
120 	937.5
121 	945.3125
122 	953.125
123 	960.9375
124 	968.75
125 	976.5625
126 	984.375		986		-1.625
127 	992.1875

[frsimen]

The main HF150 synthesiser tunes in 1kHz steps, with the interpolation oscillator filling in the gaps.

Looking at the numbers, it appears to use 8 bits, giving 256 steps. 1kHz divided by 256 is 3.90625Hz. Multiplying that by your decimal result gives good agreement with the fraction of kHz.

E.g 213x3.90625=832Hz

Paula

[SiriusHardware]

I'll try generating another table (tomorrow) based on that concept. If it works, it gets rid of that troublesome right hand bit that we don't know what to do with.

Great to have such a keen team working on this problem.

[John KC0G]

On page 7 of the HF-150 Technical Manual it states that the HET frequency (ie the interpolation frequency) can be controlled in 128 steps across its 1 kHz range, each step being nominally 7.8 Hz. My comment is that this will be set in the firmware, and is independent of the encoder pulses per revolution. The encoder ppr sets the tuning rate, not the tuning resolution.

Looking at SiriusHardware's numbers, and following on from my earlier edited post it seems that:
the decimal number = INT(last three digits * 0.256) with a range of 0 to 255
and:
the control number = INT(decimal number / 2), with a range of 0 to 127
If this is correct, the sent number uses 8 binary digits, but only the 7 most significant digits are used as the HET control.

Please, if Jez were up to doing more tests, these numbers might help:
0.039 kHz, decimal number = 9.984, sent number = 0000/1001
0.961 kHz, decimal number = 246.016, sent number = 1111/0110

Thanks and 73

John KC0G / M0KCY

[jez_145]

Originally Posted by John KC0G

Hello Jez and Sirius

Hello 2U2 John KC0G (and now also Paula) !


It's now the morning. I had a quick look at this thread before I went to bed last night to see the comment from John about the 7.8125 Hz tuning steps -- W H A A A T ! This was news to me. I'd always taken the minimum tuning step size to be a nice, round 8Hz (I knew that the rate increased depending on mode and spin rate etc).

I went to bed, but not before taking a look at the HF-150 user manual and, in particular, the Circuit Description on page 27 which has a paragraph stating:-

"Receiver tuning is achieved by varying the frequency of both the local oscillator and the IF conversion (heterodyne) oscillator. The local oscillator covers 45.030MHz to 74.999MHz in 1kHz steps, and fine tuning is provided by the heterodyne oscillator covering 44.544MHz to 44.545MHz in 128 steps...."

Bingo! Light bulb moment

(44.545MHz - 44.544MHz) / 128 = 7.8125 Hz

I see it now !

This also explains the six versus eight bit burst strategy. If the user enters a frequency in full kHz, this will be applied to the local oscillator (and the hetrodyne osc just zeroed presumably?) But, if a fractional frequency is entered, the integer part (6 burst) will be applied to the local osc, and the fractional part (burst 8) will be applied to the hetrodyne osc.

Since realising that, I noticed John's and Paula's later comments - great stuff - we're all thinking on the same lines. Last night I was thinking maybe they just used a lookup table or something to resolve the fractional part but, now, probably not.

John, I'll try the 0.039 and 0.961 FRQ commands later this morning. Going to have some breakfast and get the shopping in first !

Cheers,

Jez

[jez_145]

Ok, I've attached the final (burst 8 only) output for the 0.039 and 0.961 frequencies requested by John. I've also included scope shots for 0.997, 0.998 and 0.999 so that we can see what happens at the end of the fractional range.

enjoy ! (as they say)