Примітки NMAxe v3.1.03 додають підтримку плати Nexus і гарантії відновлення
Публікація джерела: 2026-09-22 · Редакційний аналіз опубліковано: 2026-09-23
У репозиторії NMAxe перераховано версію 3.1.03 із підтримкою NMQAxe++ Nexus, автоматичним визначенням плати та відновленням HCN. Оператори повинні перевірити активи релізу для конкретної моделі перед перепрошивкою.
Аналіз і практичні висновки
У цьому розділі — наш аналіз та умовні розрахунки, окремо від повідомлення джерела.
Що опублікував репозиторій
Репозиторій ESP-Miner-NMAxe додав запис від 22 вересня для версії 3.1.03. Його примітки до випуску описують підтримку плати NMQAxe++ Nexus за допомогою ASIC BM1373, автоматичне визначення версії плати, логіку відновлення та зміни інтерфейсу користувача. Це прошивка з відкритим вихідним кодом для сімейства компактних біткойн-майнерів, побудованих на керуючому обладнанні ESP32. Примітки є попередньою інформацією про проект, а не тестом, виконаним ASIC.tools. Під час нашої перевірки окрема сторінка випусків сховища все ще відображала v3.1.02 як останній пакетний випуск, тому користувачі повинні підтвердити, що відповідні ресурси v3.1.03 дійсно доступні, перш ніж намагатися оновити.
Підтримка Nexus і ідентифікація плати
Версія 3.1.03 додає новий варіант плати NMQAxe++ Nexus на основі BM1373. У примітках також зазначено, що QAxe++ і QAxe++ Rev6.1 можна розрізнити під час завантаження за допомогою шпильки GPIO46. Якщо мікропрограмне забезпечення не відповідає виявленій платі, інтерфейс має відобразити повноекранне накладення неправильної мікропрограми з назвою плати замість мовчазної помилки. Цей запобіжний захід зменшує неоднозначність, але не робить кожен двійковий файл універсальним. У попередніх інструкціях проекту сказано, що користувачі повинні вибрати прошивку для конкретної моделі пристрою. Оператори повинні записати версію PCB, тип контролера та поточний образ перед завантаженням.
Автоматичне відновлення HCN
Нова автоматична повторна ініціалізація HCN призначена для реагування, коли програмне забезпечення виявляє дисбаланс каналів, відсутність каналів або відсутність прогресу. Майнер може виконати швидке відновлення циклу живлення Vcore з принаймні п’ятнадцяти хвилинами між спробами. Обмежений інтервал є корисним, оскільки повторне ввімкнення живлення може приховати постійну несправність апаратного забезпечення, живлення чи тепла. Після оновлення відстежуйте кількість відновлення, хешрейт окремого каналу, температуру, напругу живлення та частки пулу. Якщо той самий канал неодноразово падає, збережіть журнали та перевірте роз’єми, охолодження та якість живлення замість того, щоб розглядати автоматичне відновлення як доказ того, що основну проблему вирішено.
Попередні налаштування, результати тестування та обмеження
У примітках до випуску наведено робочі налаштування ECO, Normal і Turbo, а також контрольні діаграми, які можуть зберігати приблизно від 28 до 80 історичних результатів. Вони також згадують обмеження частоти та Vcore до апаратних обмежень. Попередні налаштування — це зручні відправні точки, не гарантовані стабільні налаштування для кожного зразка ASIC, джерела живлення чи температури навколишнього середовища. Конфігурація, яка дає короткий контрольний пік, може забезпечувати гіршу ефективність прийнятої частки протягом годин, якщо помилки, нагрів або дроселювання збільшуються. Порівняйте прийнятний хешрейт і потужність стіни після теплової рівноваги та збережіть заводську базову лінію, щоб проблематичну зміну налаштування можна було скасувати.
Захист від охолодження та напруги
Згідно з примітками, версія 3.1.03 додає безпечну межу швидкості вентилятора та виправляє зміщення калібрування Nexus Vcore. Ці зміни безпосередньо впливають на теплове та електричне керування, тому відповідність моделі є важливою. Не копіюйте значення напруги з іншої версії плати лише тому, що веб-інтерфейс приймає його. Перевірте роботу вентилятора перед майнінгом, стежте за температурою ASIC і регулятора та уникайте тестування без нагляду після серйозної зміни прошивки. Програмна стеля не може компенсувати заблокований радіатор, незакріплений роз’єм, занижений блок живлення або неправильне зчитування датчика. Зупиніть пристрій, якщо температура або електрична поведінка істотно відрізняються від відомої базової лінії.
Зміни завантаження, інтерфейсу та API
У проекті сказано, що стабільність запуску покращено, а інтерфейс оновлення тепер показує часову шкалу версії з примітками до випуску, синхронізованими зі сховища GitHub. Відповіді API отримують поле maxTarget і запис останнього результату оновлення по повітрю. Ці поля можуть допомогти інформаційним панелям автопарку відрізнити доступний ліміт від вибраного налаштування та визначити невдалі оновлення. Автоматизація повинна обробляти нові або відсутні поля оборонно: спочатку запитайте один тестовий блок, збережіть стару схему відповіді та оновіть аналізатори перед широким розгортанням. Відповідь HTTP, у якій повідомляється, що OTA завершено, все ще не замінює перевірку запущеної версії, підключення до пулу та прийнятих спільних ресурсів після перезавантаження.
Обережна процедура оновлення
Спочатку експортуйте або фотографуйте налаштування басейну, мережі, частоти, напруги та температури. Визначте точну модель і версію друкованої плати, потім отримайте відповідне зображення з офіційного репозиторію або офіційного веб-прошивки та перевірте назву файлу та контрольну суму, коли вони будуть опубліковані. Оновіть одну некритичну одиницю зі стабільною потужністю; не переривайте стирання, флеш або перше завантаження. Підтвердьте запущену версію, конфігурацію, поведінку вентилятора, виявлення мікросхем і прийняття пулу. Дотримуйтеся цього протягом повного періоду розігріву перед тим, як розширити флот. Зберігайте доступним задокументований дротовий метод відновлення, оскільки збій OTA може потребувати прямого спалаху ESP32.
Успішне завантаження — це лише перший крок перевірки. Переконайтеся, що кожен канал ASIC виявлено та що надіслані спільні ресурси прийняті запланованим пулом. Зберігайте послідовні журнали тестового блоку, оскільки вони можуть виявити помилки скидання або калібрування, які приховує середнє значення приладової панелі. Відкат, якщо стабільність, температура або ефективність погіршуються.
Що залишилося перевірити
Запис README є цінною документацією, але операторам все одно потрібен випуск із тегами, ресурси для завантаження та контрольні суми, які відповідають їхнім дошкам. Перевіряйте відкриті питання щодо проблем, пов’язаних із пристроєм, і не припускайте, що дата README доводить, що образ завершив пакетування випуску. ASIC.tools посилатиметься лише на перевірене вихідне завантаження та не віддзеркалюватиме непідтверджений двійковий файл як офіційну мікропрограму. Поточні докази підтверджують обмежений висновок: документальний проект версії 3.1.03 містить функції для Nexus і пов’язаних плат, включаючи безпечнішу поведінку виявлення та відновлення, тоді як кожен користувач все ще повинен перевірити точну сумісність апаратного забезпечення та доступність активів перед перепрошиванням.
Перед розгортанням групи збережіть точну вихідну URL-адресу, тег, хеш фіксації, контрольну суму файлу та час встановлення для тестового пристрою. Цей запис дозволяє оператору відтворити зображення та визначити, чи справді два майнери запускають ідентичний код. Використовуйте період обслуговування, локальний доступ і завідомо справну резервну копію налаштувань. Після перезавантаження порівняйте частоту, напругу, температуру, швидкість вентилятора, прийняті та відхилені спільні ресурси та потужність стіни з базовим рівнем перед оновленням. Дивіться достатньо довго, щоб вловити п’ятнадцятихвилинний інтервал відновлення, описаний у примітках. Якщо дошка явно не вказана як підтримувана, зупиніться та запитайте у попереднього проекту, а не вибирайте зображення з подібною назвою. Прошивка може покращити захист, але ретельна ідентифікація та поетапне розгортання залишаються найнадійнішим захистом від збою, якого можна уникнути.
Джерело: NMminer1024 / GitHub ↗
Калькулятор майнінгу ↗
