DDS VFO - AI-Board Design - AI-Firmware - AI-Production.

[TM007]

Here I'm at it again with this blasted AI shite . Actually i hope some of you can help.

So why am I here, there are plenty of good folks providing DDS VFO's on both sides of the pond after all and reasonably priced from what I can see, I don't own one, well not a modern one (last 5 years or so). I watched many videos and read much from various sources but I assure you I will have missed some of the obvious stuff without doubt. There are some common themes with all of these boards:

Si5351 - Sometimes Ver A chip (no VCO), sometimes Ver B with VCO and sometimes a TCXO.
ESP32 or similar.
TFT screen of various sizes.
Rotary encoder etc.

Looked over some of the work done by M0XFX and others. Nothing ever seemed to be absolutely finished, some projects just didn't progress (quite possible with this attempt also) and none seemed to have it all, whatever that is? I'm not sure. Couldn't find any public boards on PCBway etc. to try my hand.

I know zilch about pcb design.... I know about KiCad the same as I know about Burger King! I know about PCBWay and others but never used them to produce anything. I know a little about code (not my happy place in IT).

So given that self awareness I thought why not get AI to do most if not all of it! BUT this time using Claude (Free Tier) not CoPilot (which would be crap for this even on my paid version). As i've said in other threads about AI, its handy to know a little about what you are trying to achieve, even better if you collate that information in an easy to manage folder purely for the AI task is not possibly getting something onto GitHub if worth it in the future. Also helps to know a little about AI models and limitations. All of these can be addressed using AI itself.

As an example before i get into the main part of this thread, I'm using Claude not Claude Code with is not free, Claude has a free tier. There are limits on the amount of files you can upload in each prompt (5 i think) and I had 33 files I wanted Claude free to tackle. So how to tackle that? well get Google Gemini (free) to tell me how to circumvent that limit in a way that i can upload all 33 files before uploading my main prompt. NICE!

Next, use Gemini to work on the big ask (Prompt), basically me telling it everything in one go as best I can that i want it to do/achieve. How to best structure that big prompt and refine that prompt using Prompt Cowboy on free tier Sonnet 5.5 model.

So basically I'm typical tight Scotsman not willing to pay for AI tokens if i can help it....

Last and certainly not least I'm hoping some of you who absolutely know what you are talking about when it comes to RF engineering and years of experience can help me to the point where some hardware appears (stretch goal really).

****PROMPT BEGINS****


I have attached the VFO ESP32-S3 repository: `/_VFO_ESP32S3/` (19 `.ino`, `.cpp`, `.h` modules), the legacy schematic in `/circuit_diagram/`, the active BOM in `/parts_list/`, and 10 development transcripts in `/video_transcriptions/`, including "VFO ESP32-S3.txt". Work from these files, not from assumptions about the project.

Act as a senior RF hardware engineer and mixed-signal systems architect. Analyze the files and produce a hardware engineering specification that serves as the blueprint for drawing schematics and routing a commercial-grade, low-noise SMD PCB in KiCad v10.0, manufactured by PCBWay.

**Hard rule, applied before anything else:** use only facts found in the attached files or stated in this prompt. Do not infer, extrapolate, or guess component values, trace widths, or pin connections. Wherever a critical metric (a decoupling capacitor value, an LDO current limit, a pin mapping) is missing, or the legacy circuit diagram contradicts "A look at the Band Surfer VFO ESP32-S3", stop at that item. Do not resolve it yourself. List it in a markdown table (item, source A claim, source B claim, why it matters) and wait for my manual verification before specifying anything that depends on it. Everything not blocked by an ambiguity may still be specified; mark dependent items "pending verification". The reason: a wrong guess in an RF board costs a fabrication run, and I would rather answer a question than respin a PCB.

**Target board**
- Maximum 100mm x 80mm. The board must fit inside a normal mobile CB radio / 10m export-model transceiver. A larger board may be proposed only if you justify it against that enclosure.
- 4-layer stackup: Signal | Ground plane | Power plane | Signal, for RF isolation, shielding zones, and low-impedance return paths.
- Rails: 12V DC input with reverse-polarity protection, dropping to a clean 5.0V middle rail, then a highly regulated 3.3V rail for the ESP32-S3 and I2C peripherals.
- Connectors and pots remain through-hole (THT) for physical durability.

**Functional requirements the hardware and pin architecture must natively support**
- Dual VFO: independent VFO-A and VFO-B operating concurrently.
- S-Meter: analog RF signal capture boosted by an LM358 op-amp into the ESP32-S3 ADC lines.
- Memory backup: persistent state retention in a 256kbit (32KB) FRAM over I2C.
- Split VFO: cross-channel operation (e.g., receive on VFO-A, transmit on VFO-B) driven by active transceiver sense lines.
- Lock function: lockout of the primary rotary encoder inputs via long-press.

**Design decisions already made**
- Use the SI5351B variant: its VCO function is required for FM modulation.
- The SI5351 does not need to remain a separate board. Integrate it into the DDS VFO circuit design on the main PCB, and specify a TCXO as its reference.

**High-priority engineering fixes to resolve in the design**
- GPIO crosstalk: a shared GPIO makes the NeoPixel flash erratically during Adafruit Seesaw I2C communication. Isolate it and correct the routing and pin assignment.
- Power rail segregation: isolate the 12V/9V analog lines feeding the LM358 signal booster from the noisy 3.3V digital lines driving the ESP32-S3 WiFi and I2C buses.
- RF mitigation: define explicit shielding cans or copper keep-outs around the SI5351 high-frequency local oscillator lines to protect the radio front-end from phase noise.

**Mandatory first section, "Morning Anchor", before any schematic detail**
1. The minimum engineering path required to translate this repository into a hardware schematic.
2. Architectural vulnerabilities, scope creep, and hidden risks found in the codebase or legacy schematics, formally flagged.
3. Exactly 3 high-impact, concrete action items to optimize the physical layout right away.

**Then deliver these three outputs**
1. **KiCad v10.0 schematic plan:** map the 3.3V, 5V, and 12V nets, and show where decoupling capacitors and reverse-polarity protection belong.
2. **Pin allocation matrix:** every active ESP32-S3 GPIO, cross-checked against the firmware modules, with the NeoPixel/I2C collision explicitly flagged and corrected.
3. **Layout and shielding strategy:** how to partition the board area so digital switching noise cannot bleed into the RF oscillator tracks.

**Style:** clinical, ultra-dense engineering text fragments. No pleasantries, preamble, or closing summary. No code stubs, placeholder footprints, "// TODO" notes, or temporary workarounds. State facts only.

****PROMPT ENDS****

 

[brandon7861]

Clock chips like the 5351 and DDS chips are two different beasts. If you want a digitally synthesized sine wave, don't use the Si5351. If you plan to filter it somehow, then the 5351 square wave is probably fine.

Remember that even a working code is not necessarily an ideal code and AI may not fully understand your use-case, so give it as much functional detail as possible.

If using the 5351, does it turn off unused outputs and PLL's or let them run while doing nothing (besides adding noise to the board)? Make sure that having them off when unused is the default.

When the code first learns what frequency you want, it should probably try to pick the best PLL VCO frequency based on the frequency you want to operate around so that most of the smaller frequency steps are done in multisyth (the divider after the PLL) as much as possible to prevent PLL resets. This is because when the VCO frequency has to change, the PLL must be re-written and reset too. Fractional and odd integer multisynth add phase noise and spurious signals compared to even integer multisynth, but, you are sort of stuck with it when making a VFO. I recommend eliminating the resets as much as possible by first having it determine the ideal VCO frequency for the range your VFO is operating on to minimize the chances of it having to take a different VCO/PLL route. It's something to ask your favorite AI about because I probably butchered that explanation.

 

[TM007]

Thanks @brandon7861 this is exactly the sort of detail I'm hoping to accrue here.

This is basically a test of the possible again but maybe more if it lends itself to something practical and worthwhile. For now I'm happy to pursue this with no expectation of success, only a exercise in honing my understanding of both DDS tech and AI. If something worthwhile comes out of it that's the intention, if not, then no harm in trying.

Much of what I have fed the AI is other projects found on the web, snippets of board design, code, hardware etc. M0XFX's Band Surfer project is what has provided inspiration and where possible some detail.

I must admit as I'm not a skilled electronics person there are things I simply may miss, that's where I'm trying to engage aspects of AI to keep on the straight & narrow and of course feedback from the contributors on here. That's the hard part, as you have politely highlighted, Is it aware of:

Filtering for a frequency range.
Multisynth.

I'll post the reply I got from Claude to the initial Prompt in the next post. Spoiler Alert it came back with a lot of detail but specifically gave me 14 Blockers that need resolved, more on that in the next post.

 

[TM007]

So, I've tripped up at the first hurdle. Trying to save tokens by making an efficient prompt. Trouble is I gave it a mix of information that is not succinct. Trying to do too much i.e. getting into the code specifics at the moment is not a priority and has complicated things no end. Mixing transcripts from vids with incorrect pcb references and so on.

All in all its a mess! we'll that's the nice way of putting it. I'm posting the full response below anyway but i intend to restart a new prompt and simplify the goal on the next run. Some of you well weathered RF Techs might have a chuckle at the response but overall I thought it did a good job of saying "There's a lot you have to know to fix this over to you Human, cos I ain't doing it for you" which to be fair is what i asked it to do if things were junk. I just didn't think it would be that wrong, my input data that is.


AI RESPONSE:

I'll work from the files on disk. First, the file-reading skill, then the sources in priority order: the main firmware, then the key transcripts.
The overview is too small to trace nets, so I'm zooming into the regions that matter: the ESP32-S3 symbol, the sense network, the analog stage and power.
Last schematic check: the encoder, CD4013 and 3-pin header wiring, which the pin matrix depends on.

1. Morning Anchor​

Coverage. Read in full or targeted: main .ino, all display, FRAM and clock modules, the legacy PDF (net-traced from a raster render), and the A-look, New-Si5351, Playing-With, DDS-Prototype and LO-in-Old-Radios transcripts. PART-3 and PART-4 were read at their power, encoder, parts and NeoPixel passages. PART-1, PART-2 and SI5351_VFO_002.ino were keyword-scanned only. si5351x.cpp (third-party library) was not read.
1. Minimum path from repository to schematic

• Clear the verification gate (section 2). No dependent item is specified before then.
• Freeze the GPIO map against firmware and legacy labels.
• Define the module-level block: EN, boot, USB, strap circuitry. None exists in the repo.
• Build the power tree: 12V in, protection, switch node, 5V, 3.3V.
• Define the SI5351B + TCXO + VC reference block.
• Split the analog front end (LM358, squelch) from the digital sections.
• Draw the sense dividers, the encoder chain, the I2C bus and the connectors.
• Run ERC, then fix the PCBWay stackup and design rules before routing.

2. Formally flagged vulnerabilities and risks

• Repo completeness. The prompt states 19 firmware modules and the legacy .sch. The upload has 17 ESP32 files (plus one Nano-era .ino) and a PDF only, with no EAGLE source. parts_list_v3.txt is a pointer to a transcript. Folder structure is flat.
• Wrong-board source. The DDS-Prototype transcript describes a different board (Renesas RA4M1, 16:1 mux, LDO with MCU inhibit, 13.8V input). It is not ESP32-S3 evidence. It is used here only for SI5351B/TCXO facts.
• Hardcoded credentials. wifi_SSID/wifi_Password are plaintext in the .ino.
• Boot blocking. while(!Serial) precedes CLK_SI5351.begin() in setup(). Standalone boot may block, depending on a serial configuration the files don't state.
• Dev-board dependency. The legacy design relies on the dev board's onboard 3V3 regulator and USB path (PART-3, PART-4). A bare module has none, so EN/boot/USB/3V3 must be designed from scratch.
• Unprotected analog inputs. The LM358 V+ is the switched 12V net, with no decoupling shown at IC4. The output goes through R19 to a 3.3V-domain ADC pin with no limiter drawn.
• No sense-input protection. Sense inputs have only a divider, although the DDS transcript says vehicle installation is the target.
• Scope creep. All of these are present: seesaw channel encoder, WiFi/UTC, MAX7219, LCD2004 (stub), CLK1 (marked WIP), and two displays enabled at once.
• Unused cell. LM358 section B is tied off (pins 5/6 to GND, pin 7 open).

3. Three layout actions

1. Partition into three zones (RF/clock, analog, digital/WiFi). Put the RF zone farthest from the module antenna edge.
2. Keep L2 as one unbroken ground plane under all zones. Split L3 into 12V_SW and 3V3 pour regions so analog 12V never shares copper with the 3.3V digital rail.
3. Place SI5351B, TCXO and their local decoupling in a shield-can footprint region with a copper keep-out and via fence. Route the LO outputs out of that region only.

2. Verification gate (blocked items)​

ID	Item	Source A	Source B	Why it matters
V1	NeoPixel/GPIO collision	A-look and PART-4: NeoPixel flashes because a GPIO is "shared." No GPIO number given.	Firmware: SS_NEOPIX 6 is a seesaw-chip pin index, not an ESP32 GPIO. ESP32 GPIO6 is the squelch ADC. Only sspixel.show() is called once.	The fix depends on which node is shared. I am not selecting one.
V2	FRAM I2C address	Firmware: 0x57.	Legacy: A0, A1, A2 and WP each go to GND through jumper symbols. A-look: "default is 50, mine's a bit different."	Strap pins and firmware constant.
V3	SI5351B + TCXO + FM	New-Si5351 and DDS transcripts: B variant with 25 MHz TCXO (±2 ppm) and FM through VC. The schematic video is not in the repo.	Playing-With: VC demo used a discrete 25 MHz crystal (8 pF), not a TCXO. Firmware has no VCXO/FM path (init(CRYSTAL_LOAD_8PF…), CLK0 only).	The XA/XB reference topology and VC network can't be drawn. The "DDS VFO circuit design" to integrate with is not in the repo, only a transcript.
V4	SI5351 I2C address and calibration	si5351x.h: base address 0x60. Firmware Cal_si5351 122360 is for the crystal breakout.	Playing-With: B variant address stated as "0x40" (uncertain). Calibration transcript: figure is per module.	Address plan. The TCXO changes calibration.
V5	VFO-A/B concurrency	Prompt: concurrent operation. A-look says "totally independent."	Firmware: only CLK0_FreqGen. VFO-A/B are stored separately, but one value drives CLK0. CLK1_ENABLE is WIP.	Number of RF outputs, filtering and connectors.
V6	LM358 supply rail and ADC limiting	Prompt: "12V/9V analog lines."	Legacy: V+ is SWP (switched, post-D1 12V). 9V (7809) feeds only J4 for the mixer. No limiter before GPIO5.	Rail allocation, whether a 9V rail exists, and the clamp topology.
V7	3.3V LDO	Prompt: highly regulated 3.3V.	Repo: VDD comes from the dev board's regulator (PART-3). No LDO part, current limit or load currents anywhere.	LDO selection.
V8	Decoupling values	PART-1: 47µF ×3, "anything over 10µF." Parts list: 25V.	Legacy symbols: 16V. Playing-With: SI5351B VDD "4.7" (no unit) plus 10 nF; regulator caps unit unclear. Nothing for ESP32, LM358, 4013 or FRAM.	No value can be placed.
V9	I2C pull-ups	Legacy: none drawn on SDA/SCL.	Playing-With: level-shifter pull-ups in the prototype, no values.	Five devices on one bus.
V10	Sense thresholds	A-look: TX8 high "over 5V" up to 16V.	DDS: "4V to 16V." Firmware: analogRead > 1000 with ADC bits and attenuation unset. Legacy: 10K series / 2.2K shunt per channel.	Divider validity.
V11	Module-level data	Legacy parts list names ESP32-S3-WROOM-1-N8R8.	No module datasheet or pad map in the repo. The legacy symbol is the dev board (J1/J3). Not in repo, so not asserted: reserved pins (36/37 encoder, 45/46 TFT), ADC2 use of GPIO14 with WiFi, EN/GPIO0 handling.	Pin-matrix validity and boot circuit.
V12	Input range and protection	PART-3: "10 to 16V" at the jack, also "5 to 24 volts."	DDS: 8 to 16V. Legacy: series 1N4001, with regulator limits not in the files.	Protection topology and regulator choice.
V13	Encoder supply and levels	Legacy ENC-P jumper selects VDD or SWP. Encoder rated 5V. PART-3: 3.3V is "not enough."	Prompt: 5V middle rail. The 4013 and pull-ups sit on VDD.	Whether the 12V option is dropped.
V14	Fabrication constraints	Prompt: PCBWay, 4-layer.	No stackup thicknesses, trace/space, via or impedance data in the files.	Trace widths and RF line geometry.

3. Outputs (items depending on V# are marked PV)​

3.1 KiCad v10.0 schematic plan​

Sheet	Contents (from sources)	Status
PWR	EJ508A jack (J2), reverse-polarity element immediately after the jack, PWR/SW switch node (legacy J1/J3, net SWP), 5V stage, 3V3 stage	Topology only. Parts PV(V7, V12).
MCU	ESP32-S3-WROOM-1-N8R8, EN/boot/USB	PV(V11)
CLK	SI5351B, TCXO, VC network, VDDO pins tied high (Playing-With), CLK0 out	PV(V3, V4, V5)
AFE	LM358 non-inverting stage, TM1 100K trimmer, R17/C9/J5 SSIN, R19 to SS; squelch Q1 2SC1815, R15, R16, C10, J6 SQLM, JP3	PV(V6)
SENSE	7-pin header (GND, AM, FM, USB, LSB, CW, TX8), six 10K series (R3–R8), six 2.2K shunt (R9–R14)	PV(V10)
UI	S1–S6, optical encoder header, ENC-P, CD4013 (D=A, CLK=B, Q1=DIR), R1/R2 10K to VDD	PV(V13)
DISP	9-pin ILI9341 header (VDD, GND, CS, RESET, DC, MOSI, SCK, LED, MISO), SSD1306 4-pin headers (both pin orientations), MAX7219 5-pin	Pass-through
MEM	MB85RC256V (Fujitsu, per PART-4), address and WP straps	PV(V2)

Rails.

• 12V_IN feeds 12V_PROT, then 12V_SW.
• 12V_SW feeds the LM358 V+ (legacy) and the 5V stage.
• 5V feeds the encoder VCC (PV V13), the TFT LED pin (legacy, direct) and the 3V3 stage.
• 3V3 feeds the ESP32-S3, ILI9341 VDD, SSD1306, FRAM, MAX7219, SI5351B and the 4013 VDD (legacy VDD = MCU rail).
• A 9V branch (7809 → J4) exists in the legacy design only. PV(V6).

Decoupling slots (values PV V8).

• One at each regulator input and output.
• One at each IC supply pin: SI5351B, TCXO, ESP32, LM358 V+ (absent in legacy), 4013, FRAM.
• One bulk slot per connector-fed rail.

Second part of AI response next post.​

 

[TM007]

second part of response:

3.2 Pin allocation matrix

GPIO	Function	Firmware	Legacy label	Status
1	TX8 sense	TX8=1, analog	A0	PV(V10, V11)
2	CW sense	CW=2	A1	same
3	LSB sense	LSB=3	A2	same
4	USB sense	USB=4	A3	same
9	FM sense	FM=9	A6	same
14	AM sense	AM=14	A7	same, PV(V11)
5	S-meter ADC	SIG_ADC_LEV 5	SS	PV(V6, V11)
6	Squelch pot ADC	SQL_ADC_LEV 6	SQL	PV(V11)
41	Squelch mute out	SQL_MUTE 41	SQL_CTL (1K to Q1 base)	Consistent
36 / 37	Encoder CLK (B) / DIR (4013 Q1)	vfo_enc_clk/dir, interrupt on 36	D2 / D3	PV(V11)
18	Band up	button1	D9 (S2)	Consistent
17	Band down	button2	D8 (S1)	Consistent
16	Tuning step	button3	D7 (S3)	Consistent
15	Speed / lock (hold ≥2000 ms = lock)	button4	D6 (S4)	Consistent
8	VFO / split (hold ≥2000 ms = split)	button5	D5 (S5)	Consistent
7	MEM	none	D4 (S6)	Unused in firmware
39 / 40	I2C SCL / SDA	SCL0_Pin, SDA0_Pin	SCL / SDA	PV(V9)
10, 11, 12, 13	TFT CS / MOSI / SCK / MISO	CS=10 in firmware; SPI pins not named	CS_0, MOSI, SCK, MISO	Schematic-only evidence for 11–13
46 / 45	TFT DC / RESET	Ucglib ctor cd=46, reset=45	DC / RESET	PV(V11)
47 / 21 / 38	MAX7219 DIN / CS / CLK	DIN 47, CS 21, CLK 38 (macro off)	D12 / D10 / D11	Consistent
35	CS_1	none	label only	Purpose not in files
48	D13	none	label only	Purpose not in files
0, 19, 20, 42–44	Boot, USB, UART0	none	symbol only	PV(V11)

Seesaw header. I2C only (VCC, GND, SDA, SCL). The firmware reads no seesaw INT line, so route no other GPIO to this header. The NeoPixel collision is not corrected here. The root cause is blocked at V1.
Button inputs. Legacy has no external pull-ups. Firmware sets INPUT_PULLUP explicitly only on GPIO15 and GPIO8. The rest rely on the ezButton library, which is not in the repo.

3.3 Layout and shielding strategy​

Region	Contents	Rules
RF/clock	SI5351B, TCXO, VC network, LO output	Can footprint plus copper keep-out. Via fence on the can boundary (pitch PV V14). Only the LO output leaves. No digital or I2C routing through the region.
Analog	LM358, TM1, squelch transistor, sense dividers	12V_SW local only. Own isolation element toward 3V3 (type PV V8). ADC traces short, away from SPI and I2C.
Digital/WiFi	ESP32-S3, TFT SPI, I2C, FRAM, switches	Module antenna end on the board edge with no copper beneath. Farthest from the RF zone.
Connectors	THT jack, headers, pots	Grouped by zone on edges: RF connector at the RF edge, sense at the analog edge, display and switch headers at the digital edge.

Stack roles.

• L1/L4: signal.
• L2: unbroken ground. No splits under any zone, so every return path stays beneath its trace.
• L3: 12V_SW and 3V3 pours with a gap between them.

Size. The 100×80 mm limit is accepted as stated. The files contain no footprint or enclosure dimensions, so fit is unverified.
LO filtering. The LO-in-Old-Radios transcript shows spurs that need a bandpass filter. It tested only an external 14 MHz filter. On-board filtering is unspecified (PV V3, V5).

I'm holding every PV item until you answer V1–V14. V3, V5, V6 and V11 gate the most downstream work.