Controlling the HF-150
 

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.

Re: Controlling the HF-150
 

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

Re: Controlling the HF-150
 

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.

Re: Controlling the HF-150
 

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

Re: Controlling the HF-150
 

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.

Re: Controlling the HF-150
 

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.

Re: Controlling the HF-150
 

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

Re: Controlling the HF-150
 

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

Re: Controlling the HF-150
 

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

Re: Controlling the HF-150
 

Thanks Jez -

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

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.

Re: Controlling the HF-150
 

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.

Re: Controlling the HF-150
 

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.

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

Re: Controlling the HF-150
 

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.

Re: Controlling the HF-150
 

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.

Re: Controlling the HF-150
 

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.

Re: Controlling the HF-150
 

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

Re: Controlling the HF-150
 

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. :)

Re: Controlling the HF-150
 

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

Re: Controlling the HF-150
 

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 :idea:

(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

Re: Controlling the HF-150
 

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) :beer: