Silver Spring mesh: a second on-air variant (fixed-AMI Aclara/NIC 511) not handled by silver_spring_mesh

silver_spring_mesh.c decodes a Silver Spring variant with an 8-bit scrambler, SFD 0xF3A0 and a 3-byte PHR. Reverse-engineering the radio on an Aclara I-210+c (NIC 511, fixed-AMI network, passive RX), I get frames that don't match that framing or scrambler — it looks like a second on-air variant.

	silver_spring_mesh	these frames
Endpoint	Badger water, drive-by	Aclara electric, fixed AMI
Framing	SFD 0xF3A0 · PHR(3) · PSDU · FCS(4)	0C 5F <ch> FF · PHR(2, inverted) · PSDU · 1-byte trailer
Scrambler	8-bit x⁸+x⁴+x³+x²+1	degree-9 x⁹+x⁸+x⁵+x²+1
CRC	CRC-32/MPEG-2, init 0xFFFFFFFF	CRC-32 init 0, top byte XOR per-length constant
Addressing	EUI-64, OUI 00:13:50 / 00:07:81	serial 00:13:50:05:00:xx…; APs 00:13:50:FF:FE:60:xx…

Verification that it's a distinct scrambler, not a mis-parse on my end:

• The 8-bit scrambler descrambles none of these frames under any of its 255 seeds (no CRC match, OUI never appears).
• The degree-9 LFSR recovers the 00 13 50 05 00 prefix on all of them, CRC-32 valid on 386/392 captured frames.
• Berlekamp–Massey gives linear complexity 9; an 8-bit LFSR can't produce that.

Transport is fully decoded (whitening, CRC-32, framing grammar, 87-channel plan, 83-slot beacon hop sequence): https://github.com/bash-tilde/silverspring-ami-rf. Payload is AES-CCM* encrypted; not attempted. I can share sample IQ.

Questions:

1. Is this fixed-AMI framing a known second variant?
2. Separate decoder, or extend silver_spring_mesh to detect both SFDs/scramblers?
3. My captures are 2.4 Msps and read as OOK under the default demod — any FSK front-end pointers for this variant?