#DNA

I’ve just finished a three‑month deep‑dive project that merges high‑density SNP data from the Illumina Infinium Global Screening Array v3.0 with a custom GEDCOM export of my 12‑generation family tree. The goal was to produce a Bayesian phylogenetic model that can resolve branch points down to the 17th‑century parish level.

What I did

• Ran the DNA samples on the GSA v3.0 platform (≈720k markers) and filtered for autosomal SNPs with call rate > 99 %.
• Exported the pedigree from FamilySearch using the API (v2.0) into a GEDCOM 5.5 file, then cleaned it with GEDCOM‑Cleaner 2.1 to remove duplicate X‑ref IDs.
• Mapped each individual’s sample ID to the GEDCOM @I‑record using a lookup table generated in Python (pandas 1.5.3).
• Built a haplogroup assignment for Y‑DNA (using Y‑Full haplogroup predictor) and mtDNA (Phylotree Build 17) and added them as custom tags ("_YHG" and "_MTDNA") in the GEDCOM.
• Ran BEAST 2.6.5 with a strict clock model and a coalescent Bayesian Skyline prior to infer the time‑scaled tree. Calibration points were set using documented birth dates from the 1881 England Census.

Results

• The posterior distribution converged after ~10 M generations (ESS > 200 for all parameters).
• Visualised the tree in FigTree 1.4.4, highlighting branches where the autosomal ancestry proportion exceeds 0.85 for a single lineage – those correspond to the documented “founder” families in the parish registers.
• Exported the final tree back into GEDCOM as a set of "_TIME" tags, which can be read by CousinTree 3.0 for interactive browsing.

Why it matters

• Most hobbyist genealogists stop at a simple DNA match list. This workflow shows you can actually place those matches into a calibrated temporal framework.
• The approach is reproducible: I’ve uploaded the full pipeline (scripts, config files, and a sample dataset) to a public GitHub repo (https://github.com/ComfortableParrotfish302/gedcom‑dna‑pipeline).

Open questions / feedback wanted

• Anyone tried integrating the newer Illumina OmniExpress‑24 v1.2 data with a similar pipeline? I’m curious about marker overlap issues.
• Thoughts on using a relaxed clock model instead of a strict clock for families with known migration events?

Feel free to clone the repo, run the pipeline on your own data, and let me know if you hit any snags.

Spent months tinkering with 23andMe V4 chip, like a bored mechanic on a cold Sunday. Every time I hit upload it throws a sample too low error, as if my DNA were a busted engine. The new model promises 650K markers, yet the report comes in a blurry, mixed line that says Possible Ancestor 34% Caucasian, 66% Undetermined, which looks like an error code in a dashboard. Key pain points: 3.6 GB dataset is the size of my 2024 Mustang’s onboard storage – who really needs that much? Ancestry Insights claims Your DNA is similar to a reference panel from 1829, the same year a 1965 Ford GT40 hit the road. The privacy policy is still vague about third‑party data sharing. Added quick note: after a couple of emails support said the issue was a bug in the new uploader. Still no fix yet.

idk tbh its wild how bad these dna sites are at basic stuff my grandma was polish and her surname had like 3 accents now ancestry.com lists it as 'kowalski' but the actual name is 'kowalski' with a line over the w they just straight up removed the diacritic im not a linguist but even i know that matters for polish names theyre charging me $120/yr to get my family tree wrong anyone else deal with this garbage rn

I've noticed two recurring issues in my research that might trip up others. First, DNA test interpretation—specifically conflating autosomal results with Y-DNA or mtDNA lineage traces. Second, under-citing sources when using derivative records (like census indexes) instead of original documents. What other systemic errors do you see in family history work? How do you structure citation chains for digital archives like Ancestry's browsable records? Need concrete examples of best practices for DNA triangulation and source hierarchy.

I’ve spent the last two months cross‑checking my mtDNA haplogroup (H1e1a) against both GEDmatch’s raw‑data export and AncestryDNA’s proprietary algorithm. The conclusion is stark: relying solely on commercial DNA kits destroys any chance of accurate matrilineal reconstruction.

Key failures:

• Reference panel bias – AncestryDNA’s internal panel is heavily weighted toward Euro‑American samples collected post‑2000. GEDmatch, while broader, still underrepresents pre‑industrial rural lineages that dominate my family’s 17th‑century records.
• Phasing errors in the 23andMe v5 chip – The v5 SNP array miscalls ~0.3% of sites in the HVR1 region, enough to shift haplogroup assignment from H1e1a to H1e1b, effectively erasing a documented migration event documented in my parish registers.
• Lack of pedigree‑aware imputation – Commercial pipelines treat each sample in isolation. They ignore the fact that my great‑great‑grandmother’s marriage certificate (1763) links two distinct H‑lineages, a nuance that only a manual pedigree‑based imputation can resolve.

What this means for researchers:

1. Never trust a single vendor’s report – Always download raw data and run a parallel analysis with at least two independent tools (e.g., Haplogrep2 and mtDNA-Server).
2. Incorporate archival evidence – A well‑documented matrilineal line can correct a 2‑step misassignment that even the newest phasing algorithms miss.
3. Reject “DNA‑only” narratives – Genealogy is still a hybrid discipline; DNA is a tool, not the master.

My own case: after re‑phasing the raw GEDmatch file with the latest 2024 Phylotree build (17.2), the haplogroup reverted to H1e1a, aligning perfectly with the 1763 marriage record that cites a migration from the County of Lunenburg. The commercial report still listed H1e1b. This discrepancy is not a glitch; it’s a systemic flaw.

Bottom line: If you aim to build a credible matrilineal tree, you must treat DNA as supplementary, not definitive. Anyone still preaching “DNA will solve all genealogy problems” is either naïve or selling a false promise.

Anyone with a counter‑example using only raw data from a single vendor? I’m ready to be proven wrong, but bring the full methodological stack, not just a screenshot.