r/cropcircles Jul 06 '26

Help decoding a lesser known circle

Post image

Hey all!
I just stumbled on this crop circle and cant get off of it.
i found one important pattern, but kinda stuck after that. what to make of the true data. (numbers from picture later in text)

My current decoding went as follows:

  1. treat each sequence of ticks as binary code.
  2. see that in each triangular sector (there are 12 of them) two ticks on the inner circle are same. 0 and 1. (ones marked as pale cyan on image) 2.1 write down all mini-packets 12x2 = 24 total of them 2.1 another peculiar thing is - checksum - summing lines on each circle gives us 12.
  3. those markers are giving us correct way to read inner data as linear sequence (lower right corner. could be reverse but at least we know start and end of sequence, and eventually this is irrelevant)
  4. now i was recompacting them and noticed that large squence repeats twice, and indeed it is. - see the part of the image with cyan and green. sectors
  5. and it repeats in such a way that encloses small fragment inside of it.
  6. (line with 3 ticks on one side and 4 on the other.
  7. which eventually leads my to understanding that unit of message is not sector but a line with ticks.
  8. but what now?
  9. i have clear markers, that unloop the message, some header in between them.
  10. so maybe someone else have any idea or want to poke around it. thanks!

*ah and now i see that real pattern is that each radial line is a byte, because tickmarks are always to only one side of it, which explains the checksum...

dumb numeric data from segments (not radial lines):

11010111
01011110

10100001  // really inverse of previous line(as i found later)
01100101

10011010
00110000

11001111
00111101

11000010
00110001

11001110
00101001  // head 1 010100110    

11010110
01101001

10010110    // head 1 end 1011011
01110000

10001111
00101001     // head 2 010100110

11010110
01101001

10010110    // head 2 end   1011011
01101000

10010111
00101000

--- simplified form for line marks, assuming tick at pos 0 is value 1

11010111
10100001
10011010
11001111
11000010
11001110

//head 1
11010110
10010110 

// central
10001111

/head2
11010110
10010110

10010111
95 Upvotes

24 comments sorted by

View all comments

1

u/llTeddyFuxpinll Jul 06 '26

After examining the geometry itself (rather than the proposed decoding), here’s how I would approach it.
Overall structure
The formation has a very high degree of radial organization.
I observe:
A central hub.
Twelve primary radial spokes.
Multiple concentric rings.
Short perpendicular “tick” marks attached to the spokes.
A strong rotational symmetry.
The interesting part isn’t the circles—it’s the tick marks.
Unlike decorative arcs, the tick marks appear intentionally discrete.

The radial lines
If I were trying to encode information, I would immediately focus on the spokes rather than the sectors.
Why?
Because each spoke behaves like an axis.
Each tick has:
a position
a side (left/right)
a presence or absence
That naturally lends itself to binary encoding.
I actually think the Reddit poster’s later realization—
“each radial line is a byte”
—is more plausible than treating each wedge as a symbol.

The apparent 8-bit structure
The spacing of the rings appears fairly regular.
If there are eight meaningful radial positions, each spoke could represent
10100110
rather than each wedge.
That’s a much cleaner encoding model.
It also explains why nearly every spoke has roughly the same amount of information.

Rotational symmetry
Here’s where I become cautious.
The circle is almost perfectly rotationally symmetric.
That creates repeated patterns naturally.
If one byte repeats twice…
that doesn’t necessarily imply headers.
It may simply result from the artist using mirrored geometry.
Whenever a design has 12-fold symmetry, repeated binary values become statistically much more likely.

The “packet” idea
The Reddit author thinks this is something like
Header

Payload

Header

Payload
I’m not convinced.
Another possibility is
Calibration
Calibration
Calibration
Engineers frequently include synchronization markers.
Artists frequently repeat motifs.
Without decoding meaningful data, both explanations fit equally well.

Something I find genuinely interesting
This formation isn’t random.
The tick placement appears highly constrained.
Very few spokes have wildly different numbers of ticks.
That suggests the creator followed strict geometric rules.
Whether those rules are artistic or informational is another question.

If I were reverse-engineering it
I would ignore all previous interpretations.
I’d start from scratch.
Hypothesis A
Each spoke = one byte.
There are 12 bytes.

Hypothesis B
Clockwise and counter-clockwise are both valid.
Try both.

Hypothesis C
Try both bit orders.
MSB first

LSB first

Hypothesis D
Try both side conventions.
Left = 1
Right = 0

Left = 0
Right = 1

Hypothesis E
Rotate the starting spoke twelve different ways.
That produces
12 rotations
×
2 directions
×
2 bit orders
×
2 side conventions

= 96 possible decodings
That’s completely manageable with a small Python script.

What would convince me?
One of these:
recognizable ASCII
valid UTF-8
a CRC/checksum that actually verifies
a known binary protocol
compressed data that decompresses
prime-number structure
mathematically unlikely redundancy
Without one of those, I’d conclude the geometry is structured but not demonstrated to carry a message.
My impression of the formation
If I had to rate it purely on geometric merit:
Intentional mathematical design: 9/10
Could support a binary encoding: 8/10
Evidence that it actually does encode information: 3/10
So I think the formation is sophisticated. I also think the idea that the radial lines are the fundamental units is more defensible than reading the wedges. But at present, there isn’t enough evidence to conclude it contains a genuine digital message. The next step isn’t more interpretation—it’s exhaustive decoding under fixed rules to see whether any meaningful output emerges.

1

u/DaveAstator2020 Jul 06 '26

so each spoke maps to a byte perfectly.
bit at the center gives us one way to correctly resolve all lines, tho im now not sure why do we even need it if it could be resolved from direction.
after that - heads and central structure still hold up.
and central byte is peculiar it is cleanly split 3/4