สัญญาณนี้ใช้ในการเข้ารหัสอะไร

ฉันมีเทอร์โมมิเตอร์พูลไร้สายราคาถูก (AcuRite 617 1 ) และฉันต้องการดักจับข้อมูลอุณหภูมิที่เครื่องรับและใช้กับระบบบันทึกข้อมูลด้วยคอมพิวเตอร์

สิ่งอำนวยความสะดวกภายในตัวรับสัญญาณเป็นกระดานแยกย่อยขนาดเล็กที่เชื่อมต่อกับเสาอากาศและมีหมุด "V", "G", "D" และ "SH" แบบดิจิทัล:

นี่คือส่วนของข้อมูลที่บันทึกจากหมุด "D" ระหว่างการส่งสัญญาณ (เกิดขึ้นหนึ่งครั้งต่อนาที) ก่อนส่วนนี้มีข้อมูลที่ดูเหมือนว่าจะมีอัตราสูงกว่ามาก แต่ฉันเชื่อว่าอาจเป็นเสียงรบกวน - นี่คือจุดเริ่มต้นของข้อมูล 1.36kHz / 680Hz

ฉันไปเที่ยวบ้างและไม่สามารถหาการเข้ารหัสที่มีลักษณะเช่นนี้ได้ แต่ถ้าฉันต้องเดาว่าเกิดอะไรขึ้นนี่คือสิ่งที่ฉันคิด:

• 4 รอบแรกของ 680 Hz คือการซิงโครไนซ์นาฬิกา แต่ไม่มีข้อมูล
• รอบ 13 ของ 1.36 kHz (2x อัตราเริ่มต้น) ที่ตามมาปรากฏว่ามีหนึ่งในสองรูปแบบ: พวกเขาทั้งสองลดลงต่ำก่อนที่จุดกึ่งกลางของรอบหรือหลังจากนั้น - ฉันจะถือว่ารูปแบบหนึ่งเป็นตรรกะหนึ่งและอื่น ๆ เป็นศูนย์
• หลังจากนั้นจะมีช่องว่างแปลก ๆ แต่ถ้าคุณลดส่วนต่ำที่เป็นส่วนหนึ่งของ "1" ก่อนหน้านั้นช่องว่างที่เหลืออยู่คือ 735 µs ซึ่งเป็นความต่อเนื่องของเฟส 680 Hz เริ่มนำ

ฉันกำลังดูสิ่งนี้ถูกต้องหรือไม่? มีชื่อสำหรับการเข้ารหัสนี้หรือไม่?

หมายเหตุเพิ่มเติมบางประการเกี่ยวกับการทำลายบอร์ด:

• บอร์ดนี้มีชื่อว่า "RF211" และมีลักษณะสอดคล้องกับวัตถุประสงค์ทั่วไป MICRF211 ", 3V QwikRadio Receiver ที่ทำงานที่ 433.92MHz" 3
• แผ่นข้อมูล MICRF211 มีรูปต่อไปนี้ (มีคำอธิบายน้อยมาก) ซึ่งดูเหมือนยั่วเย้าเหมือนสิ่งที่ฉันเห็นยกเว้นคลื่นสี่เหลี่ยมสองอัตราข้อมูลเมื่อเทียบกับการจับของฉัน:
  

อัปเดตเมื่อวันที่ 2016-02-14:ฉันได้กลับมายังโปรเจ็กต์นี้และดูเหมือนว่าจะได้รับสตรีมแบบ 64 บิตที่สะอาดระหว่าง preamble แบบ 4 รอบและแบบ "postamble" แบบ 1 รอบหลังจากที่บอร์ดแสดงผลปิดโมดูล RF โดย ดึง ^ SH ต่ำ (บรรทัดบนสุด):

ตามโครงการ "33/66% PWM" ของ Micrel (ซึ่งไม่ปรากฏที่อื่นใน Google) นั่นคือ

-_-_-_-_0000011110011000110000000000000000000000100011101000010010101010-_

ดังนั้นตอนนี้ฉันต้องเริ่มจัดการอุณหภูมิเพื่อถอดรหัสบิต ที่นี่ ("x") เป็นบิตที่ดูเหมือนจะเปลี่ยนแปลงโดยไม่มีการเปลี่ยนแปลงที่ชัดเจนในหน้าจอ:

0000011110011000110000000000000000000000100011101000010010101010
------------------------------------------------x----xxxx----xxx

ฉันถือว่าสิ่งเหล่านี้เป็นบิตที่สำคัญน้อยที่สุดหรือระดับแบตเตอรี่ (ซึ่งจะแสดงเป็น "ต่ำ" เมื่อมันลดลงอย่างมีนัยสำคัญเท่านั้น)

2016-02-15 อัปเดต:ฉันกำลังแสดงอยู่บนท้องถนนเพื่อให้สแต็คใหม่ "Reverse Engineering" แตกที่กำหนดความหมาย: /reverseengineering/12048/what-is-contained -in-นี้ส่ง-RF-สระว่ายน้ำที่อุณหภูมิเซ็นเซอร์ฐานหน่วยอีกครั้ง

Micrel หมายถึงมันเป็นโครงการ PWM 33/66% มันดูเหมือนจะค่อนข้างง่าย แต่ ad-hoc โปรโตคอล

PWM ย่อมาจากการปรับความกว้างพัลส์ มีหน้า Wikipedia ที่ให้รายละเอียดเพิ่มเติม แต่ในระยะสั้น PWM คือที่ที่คุณรักษาช่วงเวลาที่กำหนดไว้ดังนั้นนี่คือเวลาจาก edge edge ไปจนถึง Edge ที่สูงขึ้นถัดไป แต่คุณเปลี่ยนเปอร์เซ็นต์ของเวลาที่อยู่ในระดับสูง สถานะโดยการเปลี่ยนแปลงเมื่อขอบตกเกิดขึ้น สำหรับอันนี้คุณจะเห็นได้ว่าสูง 33% สำหรับ '1' และ 66% สูงสำหรับ '0'

พัลส์ชุดแรกมีค่าสูงและต่ำเท่ากัน โดยปกติจะทำเพื่อให้ผู้รับซิงค์ก่อนได้รับข้อมูลจริง

ดูhttp://www.micrel.com/_PDF/App-Notes/an-22.pdfสำหรับรายละเอียดเพิ่มเติมเกี่ยวกับสิ่งที่พวกเขาคาดหวังสำหรับโมดูล

วิธีทั่วไปในการรับการเข้ารหัสประเภทนี้คือการป้อนข้อมูลนี้ลงในพินการจับการป้อนข้อมูลตัวจับเวลาของไมโครคอนโทรลเลอร์ หรือคุณสามารถเชื่อมต่อกับอินพุตทั่วไปและให้มันตัวอย่างที่ระยะเวลา PWM 4-5 เท่า อัลกอริทึมสำหรับการถอดรหัสนั้นไม่ยากเกินไป

หรือตามคำแนะนำของ markt คุณสามารถกลับไปหาเซ็นเซอร์อุณหภูมิได้ แต่ถ้าเป็นสัญญาณเอาท์พุตแบบอะนาล็อกคุณจะต้องแปลงเป็นดิจิตอลด้วยตนเองและอาจมีตัวเลขที่แตกต่างกันเล็กน้อยในการบันทึกของคุณจากเอาต์พุตต้นฉบับ

คนที่ฉันรู้จักมักจะเรียกเทคนิคการเข้ารหัส "PWM" ซึ่งฉันคิดว่าเป็นคำอธิบายที่สมเหตุสมผล

ความคิดแรกของฉันดูที่ data stream ของคุณและสมมติว่าคุณคาดเดาขั้วของบิตอย่างถูกต้องนั่นคือการอ่าน ADC แบบ 12 บิต, LSB ก่อนโดยมี '1' เป็นบิตเริ่มต้น ฉันไปกับ LSB ก่อนเพราะการเริ่มต้นของสิ่งที่น่าจะเป็นการอ่านครั้งต่อไปแสดงให้เห็นถึงการเปลี่ยนแปลงบิตเดียวและไม่น่าเป็นไปได้ที่การอ่าน ADC ของอุณหภูมิ (พูล) จะแตกต่างกันโดย MSB ที่ 2 หรือ 3 ในช่วงเวลาสั้น ๆ

ฉันขุดลงไปอีกเล็กน้อยในระบบกลับไปที่สิ่งที่สร้างข้อมูล (ตรงข้ามกับการส่งสัญญาณ) ดูว่าคุณสามารถระบุเซ็นเซอร์อุณหภูมิและค้นหาความสัมพันธ์ระหว่างข้อมูลที่ส่งและอุณหภูมิ

แผนการส่งคลื่นความถี่วิทยุเกือบทั้งหมดจะต้องมีคุณสมบัติหลายอย่างในโปรโตคอลการเข้ารหัสข้อมูล สิ่งเหล่านี้จะรวมถึง:

1. รูปแบบที่สอดคล้องกันเริ่มนำมาใช้เพื่อล็อคตัวรับกับความถี่
2. ตัวบ่งชี้การซิงค์ชีพจรเพื่อทำเครื่องหมายเริ่มถ้ามีการระบุเฟรม
3. วิธีการในการเข้ารหัสข้อมูล 1 และ 0 พร้อมการตอกบัตรเพื่อการกู้คืนข้อมูล

พัลส์บอลคี่ที่คุณจดบันทึกไว้แน่นอนว่าเป็นตัวบ่งชี้พัลส์การซิงค์

การเข้ารหัสข้อมูลปรากฏขึ้นเพื่อติดตามสิ่งที่ฉันได้เห็นว่าเป็นการเข้ารหัสความกว้างพัลส์ นี่เป็นเทคนิคที่พบได้ทั่วไปโดยที่ทิศทางการเปลี่ยนทิศทางเดียวตามความถี่คงที่นำไปสู่เวลาบิตของความกว้างคงที่ ในระหว่างบิตเซลล์ชีพจรที่ใช้งานจะแสดงเป็น 25% ของเวลาเซลล์บิตหรือ 75% ของเวลาเซลล์บิต รูปแบบนี้ไม่ใช่พัลส์ไปสู่พัลส์ DC แบบแผนการเข้ารหัสที่สมดุลเช่นข้อเสนอการเข้ารหัสของแมนเชสเตอร์ มันเป็นเทคนิคทั่วไปที่มีการเข้ารหัสความกว้างพัลส์เพื่อให้สมดุล DC ภายในโปรโตคอลข้อความโดยการส่งบิตพิเศษเพื่อสร้างสมดุลโดยรวมในข้อความทั้งหมด ในรูปแบบที่ง่ายที่สุดข้อมูลจะถูกส่งสองครั้งพร้อมสำเนาที่สองที่มีเหตุผล

ในตัวอย่างของคุณมันเป็นเรื่องแปลกที่จะเห็นความกว้างของพัลส์ข้อมูลที่เกิดขึ้นก่อนการซิงค์พัลส์ อย่างไรก็ตามมันยังคงเป็นไปได้ที่จะเกิดขึ้นหากขั้นตอนวิธีการถอดรหัสข้อมูลได้รับการออกแบบให้ยอมรับข้อมูลที่ได้รับด้วยการซิงค์ในตำแหน่งนี้ เป็นไปได้ว่าหน่วยกำลังส่งข้อมูลประเภทหนึ่งก่อนการซิงค์และอีกหนึ่งหลัง การแยกอาจอยู่ระหว่างข้อมูลที่อยู่เซ็นเซอร์ / ข้อมูลอุณหภูมิหรือข้อมูลจริง / ข้อมูลกลับด้าน

แก้ไข:

เป็นที่น่าสนใจที่จะทราบว่ามันเกือบจะดูเหมือนว่าหน่วยส่งสัญญาณกำลังใช้อัลกอริทึมซอฟต์แวร์ที่แตกต่างกันสำหรับการกำหนดความกว้างพัลส์บวกสำหรับเซลล์ข้อมูลก่อนรูปแบบการซิงค์มากกว่าความกว้างพัลส์ที่และหลังจากรูปแบบการซิงค์ นี่หมายความว่าอาจมีก้อนซอฟต์แวร์แยกต่างหากที่สร้างรูปแบบก่อนหน้านี้มากกว่าส่วนต่อมาของรูปแบบ ความแตกต่างของรูปแบบนี้อาจหมายความว่าแหล่งข้อมูลในแต่ละกรณีต้องการการจัดการที่แตกต่างกันในแง่ของวิธีการเข้าถึงแบบทีละนิด ความแตกต่างที่เห็นในไดอะแกรมการกำหนดเวลาอาจเป็นเพียงการกำหนดเวลาการสอนหรือความแตกต่างสองครั้งในลูปการสร้างรูปแบบ

ฉันเริ่มถอดรหัส Acurite 617 แล้วและนี่คือการสังเกตเบื้องต้นของฉัน ฉันสามารถบอกคุณได้ว่าไบต์สุดท้ายคือไบต์ "ตรวจสอบ" บางส่วนและถัดจากสามไบต์สุดท้ายจะมีอุณหภูมิ ไบต์เหล่านี้จะถูกส่งไปพร้อมกับการใช้บิตที่ 7 เพื่อสร้างความเท่าเทียมกันและใช้การตอดที่ต่ำกว่าของแต่ละไบต์เท่านั้น ฉันได้เขียนโปรแกรม Arduino เพื่อเก็บข้อมูลและได้เห็นข้อความ / อุณหภูมิต่อไปนี้

40 ce c0 00 00 0c 03 be
(00 0C 03) => 0C3 => 67F

40 ce c0 00 00 0c 84 39
(00 0C 04) => 0C4 => 67F

40 ce c0 00 00 0c 05 b8
(00 0C 05) => 0C5 => 67F

ข้อมูล / อุณหภูมิอื่น ๆ ที่ฉันได้เห็นคือ:

E2 => 73F

F5 => 76F

108 => 80F (81 00 88)

109 => 80F

การใช้สิ่งนี้คุณควรจะสามารถทำการแปลง "เส้นตรง" (สมมติฐาน)

เนื่องจากฉันไม่มีขอบเขตที่ดี (และความจริงที่ว่าข้อมูลถูกส่งครั้งเดียวต่อนาที) ฉันไม่แน่ใจเกี่ยวกับเวลาของฉัน ฉันเห็นการซิงค์ HI และ LO ว่าเป็น 720 usec และบิตข้อมูลเป็น 240 และ 480 usec

หวังว่าฉันจะมีข้อมูลเพิ่มเติมในภายหลัง ฉันมีพวงของสิ่งเหล่านี้ ทันทีที่พวกเขาเริ่มรั่วฉันก็เอามันออกจากสระว่ายน้ำแล้วตากให้แห้งเพื่อใช้รอบบ้าน โมดูล 617 ในภายหลัง (ที่มีสกรูปิดด้านล่างและโอริง) ดูเหมือนจะนานกว่า

ฉันทำการถอดรหัสเพิ่มเติม ไบต์สุดท้าย (check byte) ทำให้ XOR ของแปดไบต์ทั้งหมดเท่ากับ 0FFH ตัวอย่างเช่น "40 CE C0 00 8D 0C 30", 40 xOR CE xor C0 xor 00 xor 00 xor 8D xor 0C xor 30 เท่ากับ 0FF

นอกจากนี้ฉันเอาอุณหภูมิลงไปที่ 34F และการนับเป็น 10 ทศนิยม (i, e., 00 00 0A) และที่ 80F การนับเป็น 264 ทศนิยม (เช่น 81 00 88 หรือ 108H)

จากนี้ฉันใช้ Temp (F) = 0.1811 * จำนวน +32.1889 ฉันอาจได้รับช่วงที่ใหญ่กว่าเพื่อรับข้อมูลที่ดีขึ้นถ้าฉันเห็นข้อผิดพลาด

ดูสตริงของ Rob Starling ในวันที่ 2016-02-14:

00000111/10011000/11000000/00000000/00000000/10001110/10000100/10101010 07 98 C0 00 00 8E 84 AA

XOR = FF

นับ = 0E4 หรือ 228

Temp = 73.5F