Controlling the HF-150

[SiriusHardware]

As you rightly state burst seven always has the 5-bit value 11111 because that is the 'Set fine tune' command. In fact I think you could probably send that command by itself followed by the 8-bit data burst - that is why there is a significant delay between burst 6 and burst 7, to allow the 'integer frequency set' command in bursts 1-6 to be completed, before then sending the follow up command 'set fine frequency to...' in bursts 7 and 8. Burst 7 is the command, burst 8 the data.

Your burst-8 values this time are:-

For 0.039 = 00001001 = 09 Hex = 09 Decimal
For 0.961 = 11110110 = F6 Hex = 246 Decimal

Note that these are exactly the values predicted by John.

For 0.997, 0.998, 0.999 the results for all three are 111111111 = FF Hex, 255 Decimal. That is not surprising as the requested frequency has to change by more than several Hz in order for the next 7.8125Hz step up or down to be selected.

[SiriusHardware]

111111111

(Too many ones)... should have been 11111111 of course.

[John KC0G]

Jez, thank you for your latest efforts.

So the software works in steps of 1000/256 = 3.90625 Hz. This is also confirmed by Jez's comment in post #9 that an eight burst (fractional frequency) is only output when the mantissa >= 0.004

The receiver works in steps of 1000/128 = 7.8125 Hz.

Before somebody gets completely carried away with the super super super deluxe keypad with a frequency display, please consider just how accurate the HF-150 might be. It is determined by the MPU crystal frequency (probably not a TCXO, but I would have to dig), and the end point adjustments of the HET oscillator.

Back in the 1990's, Wolfgang Franta, OE3WFA, heavily modified an HF-150, with a frequency display in steps of 100 Hz instead of 1 kHz, and whole bunch of other features. He called it the HF-195. See http://www.hard-core-dx.com/archive/1996/msg00111.html
A frequency display of 0.1kHz would be nice. Anything better is probably not justified.

73 John KC0G / M0KCY

[frsimen]

A question which begs to be asked is why does the software use 8 bits while the output to drive the VCO for the interpolation oscillator is restricted to 7 bits by the circuit design?

Was there an intention to implement (or has has it already been implemented) to use dithering to allow 3.9Hz steps to be achieved when the least significant data bit 8 is set?

John's point about the accuracy of the frequency of the two oscillators is a very valid one. It would be quite difficult to ensure that the extreme frequencies of the interpolation oscillator range were exact enough, with respect to the master oscillator, that 3.9Hz steps would make sense.

Paula

[SiriusHardware]

Next step is to try to put all of this gathered information into practice. I won't be able to do anything with this until next week at the earliest myself, but if anyone else is better placed to have a go, please do.

[jez_145]

I guess we've just got to decide where we want to go with this (if anywhere at all ?).


1) We could just document the protocol and leave it at that.

So far, the emphasis has been on the FRQ frequency change aspects but I think it would be beneficial to document the mode change and memory management functions as well. I appreciate, Sirius, that you are primarily interested in extending your existing PIC keypad project, but I still think it would be useful to have a complete reference for all the IF-150 functions (or at least those that were documented and we know about).


2) Hardware

Clearly, anyone wishing to make use of the protocol info will need to build some form of interface to connect between their chosen hardware platform (Arduino, PIC etc) and the HF-150 receiver. This won't involve much - probably just an opto-isolator, transistor and a couple of resistors. But it probably needs to be drawn up somewhere.


3) Software

There are obviously many potential applications for this so the ultimate use depends on what any particular user would have as a project. If any software is written, I would suggest that it is limited to a library, with source, for the four basic IF-150 functions (FRQ, MOD, RCL, STO) and possibly a simple example application demonstrating calls to these functions and leave it at that. An Arduino sketch/library would probably the way to go on this due, to the popularity of that platform.


4) Distribution

No one is going to become an overnight millionaire flogging a control program for a 30 year old amateur HF receiver! At the end of the day and speaking for myself at least, we're doing this for fun for a receiver we've got a bit of a soft spot for. IF, we do release anything; protocol description and/or software related material, I would propose that it would be free to use, open source with only restriction concerning commercial use. A typical GNU type of thing. Where would it be hosted ? Could/should it be offered to the (say) Arduino community? Does it need hosting or do we just keep it for our own use?


All this has re-kindled my interest in the HF-150, and I quite like the idea of building a scanning keypad that's not reliant on having a PC running alongside the receiver all the time! BUT, like I said right at the beginning, I've got too many other things that need my attention at the moment, so this isn't likely to happen any time soon.


Jez

[SiriusHardware]

For the interface to the radio, we could point people to the one described on Nick Bailey's page concerning his own version of this project - I don't have the link, perhaps you would be kind enough to repost it so that all relevant info can be found within this one thread specifically dealing with this subject.

My keypad clone draws parasitic power from the keypad port just as the original one does, the control micro has a large capacitor across its pins and a blocking diode so that when the supply voltage is occasionally bitten into by those deep pulses, the uP keeps running on the charge stored in the capacitor.

I've written quite a few Arduino sketches but I wouldn't know how to create an Arduino library, so anything I got going would be self contained / all in one in the sense of the HF-150 communications functions at least, although it might use some of Arduino's own libraries such as the Liquidcrystal and Rotary encoder libraries. I'll be more than happy to post any fragments of code that I get working here.

I was not originally looking to replicate the IF-150, only to learn its output command format so that I could write a custom sketch which would make my HF150 and a DDS frequency synthesiser module track / tune together.

If you would like to try to do a closer clone of the IF-150 which may be of more general use to more people then of course I think that would be a good thing to do.

[SiriusHardware]

I meant to mention above that anyone who just wants an IF-150 or clone can simply build Nick Bailey's hardware and request his hex code which is intended to be programmed into an Arduino Uno. All he asks is that people who want to use the project make themselves known to him and use / build the project as presented / intended. This in turn makes it a lot easier for him to support end users since they should all be using exactly the same hardware running the same code.

[SiriusHardware]

Scanning... I think is only really useful on a radio which has a squelch, partly because the continual step-change in the sound of the output from the receiver as it cycles through frequencies could be quite irritating, partly because it is the squelch gate signal (not present in this receiver) which is normally used to let the scanning circuit know when to pause.

You could turn the receiver volume knob down and try passing the record-out audio to an 'audio level derived' squelch circuit which does / does not pass the audio onwards to an external amp/speaker. The squelch gate from that could be used to provide feedback to the scanning circuit.

[jez_145]

Originally Posted by SiriusHardware

Scanning... I think is only really useful on a radio which has a squelch....

Yes, if a squelch/pause function was required, I'm sure a circuit based on the good old "Add a signal level meter to your HF-150" project could come into play - though I refuse outright to ever drill the case for that 2.5mm socket!

All I was thinking was rigging something up that would simply step through a chosen band in fixed frequency steps - e.g 5kHz steps for the broadcast bands - just to get an idea what's on. Sure. it might be a tad irritating listening to the world's slowest scanner, but at least it would save me wearing my finger nail out and ever flagging outstretched arm - not to mention the rotary encoder!

I'm sure I could come up with a few other tricks too - such as a virtual twin VFO and other little niceties inherited from the AR7030.

... one day perhaps !!

Jez

[SiriusHardware]

though I refuse outright to ever drill the case for that 2.5mm socket!

Not actually considering it, you understand, but I was wondering if there was any leeway to mount a panel mount 2.5mm jack socket on the BASE of the receiver and enough room, given the rather beefy feet on the set, to accommodate the thickness of a right-angle 2.5mm plug in the space between the base of the unit and whatever surface the set is standing on.

As mods go, it would be, to all intents and purposes, invisible -IF- there is enough room in the gap to accommodate the height of the plug. It might be necessary to buy a commercially made 2.5mm mono lead with moulded plugs on the ends to get plugs with a sufficiently low profile. The wire-it-yourself right angle plugs with the snap on covers tend to be quite chunky.

There are a lot of tiny microprocessor modules around now which have bluetooth transceivers built in - perhaps that's one way to add extra features and control input / output without drilling holes in the case. Obviously the radio is metal cased and it should be difficult for RF to get into or out of the unit, but the controller to be communicated with would only need to be inches away. Could be worth a try. Or you could mount I/R transmitters and receivers in the corners of the display window and communicate with internal add on circuitry that way.

A small microcontroller with Bluetooth and an A_D input could be used to read and broadcast the signal strength being received by the receiver over bluetooth, to be picked up by an externally situated bluetooth microcontroller which drives a real meter (via PWM output?) or a LED bargraph, etc. Or even just an S-meter app on a smartphone.

Of course putting any sort of RF device inside a nice sensitive receiver is asking for trouble even if the frequency used is far outside the coverage of the receiver but it would do no harm to try.

[jez_145]

Most of these things (bluetooth etc.) have crossed my mind too. There's all sorts of mini modules available from our friends in China these days. Anything is possible but, as you say, we don't want to compromise the RF performance. I've always tried to avoid having a computer, PC or otherwise in close proximity to the receiver - which kind of defeats the object of having an IF-150 interface in a way. There's no harm in experimenting though. The neat thing about using a microcontroller in a "deluxe" version of the keypad is the possibility of it being powered from the radio and the option to program it to "sleep" when it's not actually active. The latter may help with the RF side of things.

The other thing is how, when and where you use your radio. I do most of my listening just before I go to sleep - so it's effectively a bedside radio. Listening to the top band gang on 1933, late on, is often an entertaining and amusing way to round off your evening, but I don't particularly want a PC running, 19" rack full of equipment, umpteen power supplies and cables etc. at my bedside whilst I do so.

I'm sure the jack underneath idea would work, providing you can find a suitable right angle jack/jack lead first. There's the best part of 12mm available. Like you, the plugs I've seen tend to be a bit chunky. Probably more limited choice in 2.5mm compared to the more popular 3.5mm too.

Another idea that crossed my mind was to have a flying lead jack socket hiding away in one of the battery compartment drawers. I've never ever used the battery facility and there appears to be holes and side access that may allow this. You'd just open the drawer and plug the interface in as and when you needed it.