Hi All,
I'm new to the ATU-100, but an old hand on the PIC processors (done 100s of projects)!

I'm looking at the current hardware / firmware and already have a wish list of features.
I'll probably work through most of these.? But wondered if anyone else had something they really want/miss.

Hardware:
1. Remote display / control - required to free up enough pins for the rest of this list!
2. Add Frequency detection - using some buffering, and hardware div 4, feeding into T1CLK
3. Add multiple memories
4. Add ICOM/Yaesu interface - so that the tune button does the reduced power search, and the transceiver display shows SWR good/bad
5. Add a few switched capacitors on antenna side of the inductors instead of switching the caps from input to output
6. Add an extra inductor replay to improve short wire matching
7. Switch to a 16F18456, which has a 12-bit ADC

Software:
1. Split out the functions and definitions so that the code will build for MikroC or XC8 (but will focus on XC8 going forward as everyone can use it for free)
2. Move the PIC device specific code into the pic_init, to allow the code to build for 16f1938/18f2520/16f18456/???
3. Move the display functions to common code, that can easily switch between local or remote displays? (probably needs to free up pins/memory for other things!)
4. Use Grey codes for the relay switching, to reduce the relay switching during searches
5. Add code for the hardware changes!

I'm pretty confident about being able to complete these, anything else that anyone would really want?

Thanks,
Roger - GW6HRU

During the full capacitor and inductor searching, the current code uses straight binary values (with a change in step for the higher values).
So the smallest capacitor relay does a lot of switching.
If you think about the low order search, the loops look like this:

for (inductor=0 ; inductor<16 ; inductor++) {
? set_inductor();
? for (capacitor=0 ; capacitor<16 ; capacitor++) {
???? set_capacitor()
? }
}

I'm thinking about something like this:

for (search1=0 ;?search1<16 ;?search1++) {
? inductor=search1^(search1>>1);? // Convert binary to grey code
? set_inductor();
? for (search2=0 ; search2<16 ; search2++) {
??? capacitor=search2^(search2>>1);? // Convert binary to grey code
???? if ((inductor&1)!=0) {
???????? // Swap bits 0 and 2 to further reduce switching
???????? capacitor=((capacitor>>2)&1)|(capacitor&2)|((capacitor<<2)&4)|(capacitor&8);
???? }
???? set_capacitor()
? }
}

For a 4 bit search:
0000 ??? 0000
0001 ??? 0001
0010 ??? 0011
0011 ??? 0010
0100 ??? 0110
0101 ??? 0111
0110 ??? 0101
0111 ??? 0100
1000 ??? 1100
1001 ??? 1101
1010 ??? 1111
1011 ??? 1110
1100 ??? 1010
1101 ??? 1011
1110 ??? 1001
1111 ??? 1000

All of the patterns are searched, only one relay switches per change, and the number of relay changes is 1/2.
With the bit reversal, the capacitor relays average 40 changes per search, vs 128 for the original code.

1) Moving the code to the RP2040 from the Raspberry Pi foundation. This would make it easy to add a WiFi interface for remote control and display. The RP2040 is not very expensive, $4 without and $6 with WiFi.
For this sort of thing, I'd prefer a wired approach, setting up a reliable Wi-Fi is a pain.?
I did wonder about Arduino or Pi for the local end in a remote setup, but the PIC controllers are cheap...

2) Double up on a couple of the relays to approx. double break-down voltage on the higher impedances.
I'll consider that if I add an extra inductor.

3) Build a 100 watt attenuator into the circuit. When tuning, the signal would pass through the attenuator with about 1 watt radiated when 100 watts is input. This makes sure the radio never sees high SWR and that the relays are now switching under high load/voltage. A circuit would compare the impedance on the input and output of the attenuator to do the tuning. The SWR bridge would be used to check the tuning when the attenuator is out of circuit. For an example of this, see the Icom AH-4. See ?. I believe the service manual is available on the groups.io site.
I've looked at several remote tuners (the SG-237 service manual has the full schematic which is quite interesting).

4) Maybe separate the tuner onto two PCBs. The one PCB would be the tuner and handle all the RF stuff with space left open for some of the RF enhancements. The second PCB would contain the logic. That would allow changes to be made without having to throw populated boards away.
I'm looking at an add-on board for the current design, it will have the frequency measurement stuff on it, and maybe an I2C EEPROM.
The route I'm looking at is a switching and display board, which can be in one box or remote.

5) The best place for a tuner is at the antenna feed point. So anything to support that is good.
Yes - This is my experience, either ladder line to a local tuner, or remote tuner + coax.
I'm thinking about using cat5e/6 for the remote link cable, this should be good enough for power+control+gnd, so just one control + one RF.

开云体育

Frequency status:
I've looked at a few RF frequency detector designs, and have worked out a prototype (aka Mark I).
It uses a 74AHC14 Schmitt trigger inverter (good to 125MHz) on the front end with a 74HC393 (good to 99MHz) as a front end divider.
(just waiting for the chips and some diodes to arrive now!).
Using div8, with a synchronised clock the max T1Clkin is about 8MHz, so this should be good up to 64MHz...

To keep all the current functionality, a few pins need to move around (so pcb cuts + wires):
? The Tune button moves from RB0/pin21 to RE3/pin1 (aka MCLR\, which can be an input with a config change).
? The capacitor in/out switch relay output moves from RC0/pin11 to RB0/pin21
? The div8 output from the 74HC393 (pin 5) goes to RC0/pin11 of the PIC, this is the PIC's TMR1 clkin.

TMR1 to count for a 320us period, we get 25kHz resolution:
? // Init
? T1CON=(2<<6);? // TMR1CS=2, T1CKPS=0, T1OSCEN=0, T1SYNC\=0 TMR1ON=0;

? // Count
? TMR1=0;
? TMR1ON=1;
? __delay_us(320);
? TMR1ON=0;
? // TMR1 = Frequency in 25kHz steps


I'm looking on using a fixed frequency to memory slot lookup, so we only need to store inductor relays, capacitor + SW relays, SWR
Using a packed 8-bit for the SWR (1:1....1:8.95 in 0.05 steps), we can do this in 3 bytes.

To free up the PIC EEPROM, I'm moving the config bytes to #defines. With 3 bytes per entry, 255 bytes of EEPROM is enough for 85 memories.
By only storing the amateur bands, 85 memories is enough for 50kHz resolution up to 25MHz, then 200kHz resolution above that.

I've got some M24128 EEPROMs on order, these have 16384 bytes of EEPROM (so 5461 memories).? These are I2C so can share pins with the OLED/LCD.
With a direct map (all freq, not just amateur bands) we can use 800us sample time to get 10kHz resolution.

Just want to make sure, that I interpret your changes correctly:
1. Remote display / control - required to free up enough pins for the rest of this list! --> will this be a serial interface, to allow communication between a PA and the tuner? This is what I am currently mainly missing.

2. Add Frequency detection - using some buffering, and hardware div 4, feeding into T1CLK --> Will the tuner store the last tune settings per band ( potentially in even smaller granularity) and start tuning on a new band with the stored settings? Again this would be a great improvement, as after having a fixed antenna tuned once per band it would essentially mean no real "tuning activities" required any longer, but just switching to the known configuration.
Instead of measuring frequency, frequency could also just be communicated from the PA/Transceiver through a serial interface.

on your point four Roger, how about a couple of I2C parallel ports or shift registers on the RF deck to drive the relays, a significant reduction is connections between boards...

I've used 74HC595 for LED displays (driving ULN2003s).? I've wondered about these, and given the low switching frequency, it's an option.
By moving the pins around (and using the MCLR for the tune button) I've got the frequency input sorted without changing the functionality.
I was hoping to lose the I2C for the display, but I'll probably need that for an external EEPROM.

So have the two buttons, and the two LED pins to play with.? So probably enough to add an extra relay for the inductor chain, but not too much more.

For the remote unit, I'd prefer to use differential signalling (something like RS485) to avoid noise problems on long lines.
For DMX lighting I've used the PIC comparators on the receive side, and a CLC block to invert the Tx pin, to get a RS485 like Tx.
This will need 6 pins (for PICs without PPS) or 5 pins (on PICs with PPS).

The high end tuners have 9 capacitor relays, 9 inductor relays, with 5 output capacitor relays, so 23 channels, that's 8 more than currently used.
The 40/44pin version of the PIC is the easy option, they are only about US$0.50 more, and is a lot less messing about than using external chips.
They have 12 extra I/O lines, so enough even for the biggest config.
The remote version would lose the local buttons, so that would give the 6 extra lines needed for the differential signalling between the units.

Looking at the pins required for remote unit (in-shack):
? 5-pins for the differential Tx/Rx interface (assuming a PPS device)
? 3-pin for the buttons
? 2-pins for the oled/LCD
? 2-pin for the Red/Green LED
So this could use a 14-pin device (something like a 16F15325).
? For the Icom/Yaesu/Kenwood it would be easier to use a 20-pin device (something like a 16F15345)

Roger.

This tuner doesn't step with smallest step every time. It steps with some random step, depends on.....
So Gray code is useless here in any case.?