Hello,
HL2 supposed to arrive tomorrow. I've been looking at prospective code for the IO board.
I need to control my linear, which likes to see Yaesu band codes. Four wires, a 4-bit binary number. Yaesu calls it "BCD", but it's not BCD ( Binary Coded Decimal ).
The main board delivers the current transmit frequency to the I/O board in two forms:
1. A single byte. This is adequate to choose an LPF, and in fact, there is sample code up
in the github that does just that. It is not adequate however to communicate with something like a magloop, which really needs to know the frequency of operation to a kHz or so.
2. A five-byte number. Why five bytes? If it's to an accuracy of 1 Hz, that gets us from zero to over 1 teraHz ( 1 * 10 to the 12th Hz ). Pretty sure the system won't go that high.
Is it accurate to a tenth or hundredth of a hertz or 1/256th of a Hertz or something like that?
If it's accurate to 1 Hz, I could just ignore the bottom byte and organize the top four bytes into a count of the frequency in wuffleHz ( a unit I just made up: 1 wuffleHz is equal to
256Hz ). Four-byte ( 64-bit ) numbers are not too hard to handle, although the Pico does not support them natively.
What would be really nice would be if I could organize it into a 2-byte count of kilohertz.
That gets me up to 65.536 Megaherz, which would be enough unless I get into transverters.
Much easier would be a count of crumpleHz ( one crumpleHz = 4 wuffleHertz or 1024Hz ). I can do that by ignoring the bottom byte and then shifting everything else right by two places. Problem with that, is we still have four bytes. But do we really? A four byte count of crumpleHz gets us up over 1 GHz. Surely without a transverter we won't see over 30MHz? I'm told that the HL2 only goes up to 38MHz and doesn't cover 6M.
The highest frequency I'm interested in is 30MHz. That's 29,296.875 crumpleHz. Which fits in a 16-bit variable, no problem.
I *love* open source...
Time to dig out my Pico debug probe.
- Jerry, KF6VB