Kronometar za mjerenje brzine metka HT-X3006
Vezano uz projekt elektroničke mete za gađanje zračnim oružjem, ovdje želim proučiti izvedbu još jednog jeftinog kineskog kronometra (jedan sam već opisao u objavi Kronometar za mjerenje brzine metka). Radi se o modelu HT-X3006 koji se prodaje po cijeni 20-25 eura.
Ovo je HT-X3006 koji koristim za podešavanje moje PCP puške FX DRS Tactical 6,35 mm. Kronometar se jednostavno natakne na cijev i mjerenje može početi.
U osnovi možete kupiti 6 inačica ovakvih kronometara: HT-X3006 sa i bez WiFi funkcije te glasovne najave, kao i model HT-X3005 sa i bez WiFi funkcije te glasovne najave. Displej i osnovna elektronika su kod svih modela jednake, osim što Wi-Fi verzije imaju ugrađen WiFi modul, a Wi-Fi + Voice verzija ima i Wi-Fi i glasovnu najavu koja automatski preko zvučnika izgovara izmjereni FPS ili m/s nakon svakog opaljenja. Glavna i najvažnija razlika između modela HT-X3005 i HT-X3006 je u promjeru mjerne cijevi i fizičkim dimenzijama kućišta zbog čega ova dva modela imaju različitu praktičnu primjenu.
HT-X3005 ima vanjske dimenzije 44 × 73 × 33 mm i uski otvor od 17 mm. To zahtijeva izuzetnu preciznost pri poravnanju cijevi puške kako projektil ne bi pogodio rub kućišta. HT-X3006 je nastao upravo kao nadogradnja na zahtjev tržišta, gdje je otvor proširen na 24 mm, a vanjske dimenzije su neznatno veće 51 × 73 × 39 mm. Širi otvor značajno smanjuje rizik da dijabola ili BB kuglica pri krivom kutu pucanja pogodi i uništi unutrašnjost kronografa. Cijene sve četiri inačice su gotovo iste tako da je vjerojatno najbolje kupiti model HT-X3006 sa ugrađenim WiFi modulom i po želji također sa Voice modulom (što preporučam).
Specifikacije i mogućnosti kronometra HT-X3006 u potpunosti pokrivaju sve zahtjeve za praktično mjerenje brzine projektila te ih možete pročitati u uputama koje dolaze u paketu sa kronografom.
Osim same montaže i interne punjive baterije, najveća prednost HT-X3006 pred prethodno opisanim „bezimenim“ kronometrom je ta što ovdje imate mali, ali vrlo funkcionalan i pregledan LCD displej sa pohranom i pregledom zadnjih 120 mjerenja. Također, osim mjerenja brzine, dobivate sve klasične izračune poput energije projektila, brzine gađanja, prosječnih, minimalnih i maksimalnih vrijednosti te odstupanja izmjerenih brzina, teoretski domet (Range). Za sve vrijednosti možete odabrati prikladne mjerne jedinice. Sve je vrlo lijepo vidljivo na grafičkom displeju i praktički nemate potrebe za WiFi-jem, za razliku od kronometra koji ima ugrađen samo 4-znamenkasti LED displej. Voice funkcija za glasovno izgovaranje brzine projektila je posve razgovijetna i razumljiva te vrlo korisna u praktičnom korištenju kronometra.
Pogledati ćemo prvo unutrašnjost jednog kronometra HT-X3006 koji ima WiFi funkciju, ali bez ugrađene Voice funkcije. On će nam poslužiti za istraživanje da li je moguće presresti postojeći WiFi protokol slanja podataka i prilagoditi ga nekom drugom načinu bežičnog slanja.
Kao foto-parovi koristi se kombinacija od šest polukružno postavljenih IC emitera, koji su usmjereni na jedan IC foto-senzor (foto-dioda ili foto-tranzistor). IC emiteri su u SMD izvedbi, dok je IC prijemnik klasična foto-dioda u 5 mm kućištu sa lećom. To je dobar izbor jer takva dioda može prikupiti više IC svjetla od SMD diode i može ga bolje fokusirati na aktivnu površinu senzora.
Za detekciju signala iz foto-senzora ugrađen je dvostruki komparator LM393 (jedan za ulazni i jedan za izlazni senzor). IC fototranzistori ili fotodiode generiraju analogni signal (promjenu napona) kada projektil djelomično ili potpuno blokira svjetlost. Taj signal može biti “trom” ili varirati ovisno o vanjskom svjetlu. LM393 uspoređuje napon sa senzora s precizno definiranim referentnim naponom (koji se postavlja otporničkim djeliteljem na pločici). Čim napon sa senzora prijeđe granicu, LM393 trenutno “okine” i prebaci svoj izlaz s 0V na 3,3 V (ili obrnuto). Ovaj čisti digitalni impuls (s ekstremno oštrim rubom signala) šalje se izravno ili preko tranzistora na GPIO pin MCU-a. To omogućuje MCU-u da aktivira hardverski prekid (Interrupt) u točno mikrosekundi prolaska, bez kašnjenja koje bi uzrokovalo pogrešku u mjerenju brzine.
Glavni MCU je Runjet RJM8L151 (SC8T6). Riječ je o kineskom 8-bitnom mikrokontroleru niske potrošnje (Low-power MCU) koji radi sa kristalom na 16 MHz. Ovaj MCU vrši mjerenje vremena između dva impulsna ulaza, radi kompletnu matematiku svih izračuna i memoriranje podataka, implementira vanjske kontrole i upravlja prikazom na LCD-u. Također, preko UART komunikacije prosljeđuje podatke mjerenja na WiFi čip.
Na pločici je još punjač Li-Ion baterije baziran na danas vrlo raširenom čipu TP4056. Vidi se još jedan manji 6-pinski čip sa kodnom oznakom WJ=LOP što bi mogao biti LDO regulator napona za 3,3 V. Pretpostavljam da nije čip za zaštitu baterije (poput DW01) jer baterija već ima ugrađenu internu zaštitu.
Tu je i nekoliko pojedinačnih tranzistora od kojih neki možda rade kao pojačala ili bufferi analognog signala sa foto-senzora. Uglavnom, i ovo je dizajn baziran na jeftinim komponentama, no radi posve zadovoljavajuće. Ne možemo kod ovakvih uređaja očekivati neka brza TIA pojačala jer za to jednostavno nema potrebe.
WiFi modul se bazira na namjenskom čipu ESP8266EX. To visoko integrirani Wi-Fi mikročip (SoC) tvrtke Espressif Systems, dizajniran kao potpuno samostalno Wi-Fi mrežno rješenje po iznimno niskoj cijeni. U našem slučaju radi sa kristalom na 26 MHz, no može stabilno raditi i do 80 MHz, pa čak i do 160 MHz. ESP8266EX nema vlastitu Flash memoriju pa mu je pridodana vanjska SPI Flash memorija BoyaMicro 25Q80 (1 MB). Inače podržava do 4 MB Flash memorije.
WiFi je izveden kao zaseban modul sa izvedenim UART pinovima (TX, RX) te EN, RST, IO0, IO2, 3V3 i GND. Sa glavnim MCU-om Runjet RJM8L151 komunicira preko UART sabirnice (TX, RX).
WiFi protokol
Kronometar HT-X3006, jednako kao i prethodno opisani, podatke šalje DNS Hijacking / Captive Portal Spoofing načinom preko lokalnog ugrađenog web poslužitelja (Embedded Web Server). Kineski inženjeri su ovdje iskoristili lukavu mrežnu prečicu kako bi natjerali bilo koji mobitel da trenutno otvori stranicu kronometra, bez da korisnik mora pamtiti komplicirane lokalne IP adrese:
- DHCP dodjela adrese – Kada se mobitel spoji na WiFi mrežu kronometra (password 88888888), WiFi modul mu putem DHCP protokola dodijeli lokalnu IP adresu (npr. 192.168.4.2), ali mu kao adresu mrežnog prolaza (Gateway) i DNS poslužitelja postavi samog sebe (svoju internu adresu, koja je u ovom slučaju konfigurirana da bude 8.8.8.8).
- Provjera interneta (Internet Probe) – Moderni pametni telefoni čim se spoje na bilo koji Wi-Fi automatski u pozadini šalju tihi upit prema poznatim poslužiteljima (poput Googlea ili Applea) kako bi provjerili ima li ta mreža pristup internetu. Budući da je Googleov javni DNS (8.8.8.8) najpoznatija adresa na svijetu, telefoni i preglednici često automatski šalju pakete prema njoj.
- Presretanje prometa (DNS Hijacking) – Umjesto da tvoj upit proslijedi na pravi internet (kojeg kronometar nema), ugrađeni Wi-Fi presreće (otima) taj zahtjev. Bez obzira na to što mobitel traži na adresi 8.8.8.8, WiFi kronometra mu odgovara: “Ja sam 8.8.8.8 i evo ti moja lokalna početna stranica!”.
Kod za web stranicu HT-X3006 je izuzetno bazičan (sirov). Naredba <meta http-equiv=”refresh” content=”1″> prisiljava preglednik da svake sekunde ponovno preuzme cijelu stranicu s WiFi čipa kronometra. Budući da nema JavaScripta koji bi glatko promijenio samo brojke (AJAX), preglednik stalno iznova crta cijeli ekran, što uzrokuje iritantno žmirkanje stranice svake sekunde.
Pregledom html koda stranice može se vidjeti da sama stranica ne računa apsolutno ništa. Preglednik ovdje služi isključivo kao “glupi” zaslon (render). Svi izračuni koji se vide na pregledniku, pa čak i crtanja grafikona, obavljaju se na samom MCU kronografa i WiFi čipu, koji onda generira već gotov, statični HTML tekst i šalje ga u preglednik.
Wi-Fi čip (ESP8266EX) dakle svaki put kada se stranica osvježi šalje potpuno cijeli HTML i SVG kod u preglednik mobitela ili računala. Taj kod se svakako ne nalazi fiksno zapisan u Flash memoriji (BoyaMicro) u obliku u kojem se vidi na ekranu. Flash memorija sadrži samo statičnu strukturu (template) stranice, dok se konačni tekst generira dinamički u radnoj memoriji WiFi čipa, netom prije slanja.
Iz BoyaMicro Flash memorije povlači se fiksni dio HTML-a (template) koji je uvijek isti (npr. CSS stilovi, naslov X3006 shot chronograph, tablice, AliExpress reklama). WiFi čip ESP8266 uzima najnovije sirove podatke koje mu je glavni MCU u toj sekundi poslao preko UART-a (tikovi brzine, kalibar i masa projektila). On u svom kodu ima matematičku funkciju koja pretvara ove podatke u vrijednosti, izračune, tablice i grafikon. On doslovno u RAM memoriji ispisuje tekst poput <rect x=”39″ y=”131″ width=”38″ height=”218″></rect> na temelju tih brojki. Kada se sve to spoji u jedan veliki tekstualni niz (string), ESP8266 ga zapakira u standardni HTTP odgovor i preko Wi-Fi antene pošalje prema pregledniku.
Mogućnosti modifikacije WiFi protokola
Pregledom pločice, WiFi modula i html koda, čini se da bi promjena WiFi protokola za prijem na CrowPanelu (ESP-NOW) bila moguća na dva načina: pre-programiranjem postojećeg Wi-Fi modula preko UART sučelja na ESP-NOW protokol ili zamjenom postojećeg modula nekim modernim minijaturnim rješenjem poput XIAO ESP32-C6 modula.
Usporedba postojećeg ESP8266EX modula i XIAO ESP32-C6 pokazuje priličnu generacijsku razliku. Iako su oba čipa sposobna izvršiti zadatak za primjenu koja namatreba, XIAO donosi velike prednosti u stabilnosti, razvoju i integraciji s mojim glavnim sustavom (CrowPanel ESP32-P4).
ESP8266EX koristi stari Wi-Fi 4 (802.11b/g/n) standard, a XIAO ESP32-C6 koristi najmoderniji Wi-Fi 6 (802.11ax) i Bluetooth 5 (LE). Hardverski ESP-NOW stog na Wi-Fi 6 arhitekturi nudi znatno bolju otpornost na smetnje, stabilniju vezu i napredno upravljanje kanalima. Komunikacija između dva ESP32-C6 (XIAO) će svakako biti stabilnija nego između dva WiFi čipa različitih generacija.
Gledano s praktične strane, ESP8266EX na pločici je nema USB priključak. To znači da za programiranje i razvoj koda te praćenje što se događa na Serial Monitoru, moram lemiti žice na male padove (IO0, RST, TX, RX) i koristiti vanjski FTDI (USB-to-UART) adapter. Svako testiranje zahtijeva ručno postavljanje IO0 pina na LOW pri paljenju kako bi ušao u flash mod. S druge strane XIAO ESP32-C6 ima ugrađen USB-C priključak te je programiranje preko Arduino IDE najjednostavnije moguće.
XIAO ESP32-C6 je vrlo sličnih vanjskih dimenzija kao i ESP8266EX te bez problema stane u kućište kronometra. Osim toga, to je relativno jeftin i popularan modul tako da se ne isplati gubiti živce sa ESP8266EX.
Snimanje UART protokola
UART digitalne signale na TX i RX liniji prvo sam snimio osciloskopom.
Iz ovog snimka mogu se zaključiti četiri specifikacije:
- Komunikacija je dvosmjerna. Prvo MCU šalje paket podataka prema WiFi u trajanju cca 39 ms (žuto), a onda nakon kratke pauze od 0,63 ms WiFi odgovara paketom prema MCU u trajanju 2,6 ms (crveno).
- Komunikacija se vrši isključivo kada kronometar izvrši mjerenje. Znači, komunikacija nije konstantna ili periodična, nego se razmjena paketa dogodi samo kad prolazak projektila okine mjerenje kronometra.
- Širina pojedinačnog impulsa je 26 µs što odgovara standardnoj UART komunikaciji na 38400 bauda.
Slijedeći korak je napisati mali program koji će snimati UART promet (sniffer) na 38400 bauda. Snimanje je otkrilo da MCU prema WiFi šalje paket od točno 72 bajta, a WiFi prema MCU odgovara sa paketom od 10 bajta. Sada treba otkriti strukturu podataka sadržanih u tim nizovima podataka.
Ovdje sam nakon nekoliko sati analize razložio 72-bajtni paket na podatkovne cjeline:
- HEX 00-12: Paket započinje uvijek istom standardnom mrežnom naredbom AT+CIPSEND=0 (ASCII tekst) kojom glavni MCU naređuje WiFi modulu da otvori kanal i pripremi se za slanje podataka prema mrežnoj vezi.
- HEX 13-53: FIFO kružni spremnik za 10 hitaca × 4 bajta (Gornji bitovi tajmera + Donji bitovi + Indeks)
- HEX 54: Vrijednost težine projektila u gramima upisana je u ovaj jedan bajt kao cijeli broj pomnožen sa 100 (na primjer HEX 14 = 20 / 100 = 0,20 g).
- HEX 55-56: Vrijednost kalibra u milimetrima upisana je u ova dva bajta kao cijeli broj pomnožen sa 100 (na primjer HEX 02 D0 = 720 / 100 = 7,20 mm).
- HEX 57-60: Uvijek nule, moguće rezervirana mjesta ili sinkronizacija
- HEX 61-68: Ovo su podaci koji se stalno mijenjanju i nisam našao neki uzorak za njih. Mislim da ovo nije neki stvarni izračun, niti su to standardni float brojevi. Ovo bi mogao biti neki sigurnosni ili specijalni interni komunikacijski protokol (handshake/autorizacija) između Runjeta i ESP8266 čipa. Vrlo vjerojatno se radi Tuya protokolu.
- HEX 69: Mjerne jedinice: metričke HEX 02, imperijalne HEX 03.
- HEX 70-71: uvijek isti završni kontrolni znak (\r\n)
Što se tiče grupi od 4 bajta za spremanje brzine, prva dva bajta nose sirovu informaciju o brzini, treći bajt drži memorijsku strukturu stabilnom (32-bitno poravnanje) i uvijek je 00, a četvrti bajt upravlja sinkronizacijom i redoslijedom punjenja kružnog spremnika.
MCU brzinu ne šalje u obliku gotove vrijednosti, nego kao broj tikova, odnosno broj impulsa izbrojenih između dva prekida svjetlosne zavjese pri preletu metka. S obzirom da MCU šalje broj tikova, taj broj za vrlo male brzine (ispod cca 14 m/s) postaje vrlo velik. Kada broj otkucaja tajmera prijeđe maksimalnu vrijednost od 65535 (što je maksimalni broj koji stane u 2 bajta, odnosno FF FF), brojač se “prelijeva”. Tada se aktiviraju dva dodatna bajta (UpperBits) na pozicijama 13 i 14.
Spajanjem gornja 2 bajta (UpperBits – HEX 13 i 14) i donja 2 bajta (LowerBits – HEX 15 i 16) dobivamo jedinstveni 32-bitni broj tikova:
Ukupno Tikova = (UpperBits x 65536) + LowerBits
Obrnutim inženjeringom našao sam da je konstanta tajmera 900 000. Ta konstanta predstavlja fizičku udaljenost između dva senzora. To znači da je konačna formula za brzinu:
Brzina (m/s) = 900 000 / (UpperBits x 65536) + LowerBits
Bajtovi 13-14 (upperBits) ne pripadaju tablici povijesti i nikada se ne pomiču udesno kao naredna 4 bajta. Procesor ove bajtove koristi samo za izračun niskih brzina, te se dobivena vrijednost dalje šalje kao 2 bajtni broj.
Idemo sada vidjeti paket od 10 bajta kojeg WiFi kao odgovor na prijem podataka šalje prema glavnom MCU:
Ovi povratni paketi otkrivaju da WiFi čip uopće ne koristi standardni tvornički Espressif firmware (SEND OK), već se ovdje radi o Tuya IoT protokolu (ili vrlo sličnom prilagođenom kineskom serijskom protokolu). Provjerom Tuya Checksum matematike preko Pythona može se prilično sigurno potvrditi struktura ovih Tuya okvira od 10 bajta:
- HEX 00-01 (55 AA): U svim odgovorima se ponavlja fiksno zaglavlje (Header): 55 AA. U svijetu kineske elektronike i Tuya IoT modula, ovo je univerzalni potpis (Magic Bytes) koji označava početak okvira (Frame Start).
- HEX 02 (Fx): U Tuya protokolu, 0xF0 ili 0xF1 označava verziju protokola (obično v1.0 ili prilagođenu Tuya WiFi verziju). Budući da se ovaj bajt blago mijenja, mogu samo nagađati da je ovo moguće sekvencijski brojač paketa, indikator statusa veze (WiFi Status ili Heartbeat Response) ili dio nekog mehanizma za usklađivanje sesije.
- HEX 03-07: Ovu strukturu od 5 bajta je teško „dešifrirati“ no vjerojatno sadrži podatke o WiFi Statusu, Heartbeat Response ili druge specifične Tuya statuse.
- HEX 08-09: Zadnja dva bajta (ili moguće samo zadnji bajt) su kontrolni zbroj (Checksum / CRC). Oni se mijenjaju ovisno o tome kakvi su podaci bili u sredini paketa. To je klasični matematički Checksum. MCU zbraja sve prethodne bajtove i provjerava odgovara li rezultat zadnjim bajtovima. Ako odgovara, MCU zna da je WiFi čip ispravno prenio podatak.
Može biti da je ovo dio podataka vezan uz onaj blok HEX 61-68 koji MCU šalje prema WiFi čipu. To bi bio takozvani Challenge-Response Handshake (izazov-odgovor). Kada kronometar izvrši mjerenje, Runjet MCU šalje paket od 72 bajta koji uključuje 8-bajtni sigurnosni ključ (MAC/kripto potpis) na pozicijama 61-68. ESP8266 čip prihvaća taj ključ, provlači ga kroz svoju internu sigurnosnu funkciju (ili generira novi nasumični Salt pomoću sesije) i šalje ovih 7 bajtova natrag Runjet MCU-u. Budući da Runjet RJM8L151 ima hardverski kripto-koprocesor, kineski inženjeri su moguće iskoristili tu značajku kako bi osigurali stabilnost i integritet komunikacije između dva čipa.
Trebao bi snimiti TX i RX komunikacije jedne sesije istovremeno, te usporediti HEX 61-68 koji šalje MCU, sa HEX 02-09 kojim ogovara WiFi. Pošto se u oba slučaja radi o 8-bitnim podacima koji sigurno ne sadrže izmjerene ili izračunate podatke sa kronometra, možda postoji neka druga logička povezanost. U ovoj fazi ti podaci mi nisu značajni, pa ću se njima možda baviti kasnije.
Za moj projekt je ključno pitanje treba li MCU kronometra uopće ovaj odgovor WiFi-a za normalan rad i što ako ne dobije odgovor. Prerezao sam komunikaciju WiFi -> CPU i nije se promijenilo baš ništa. Činjenica da kronometar radi potpuno jednako i nakon rezanja RX linije mikrokontrolera znači da je uređaj radi u “Fire and Forget” načinu rada. Glavni MCU (Runjet) samo pošalje telemetriju kroz svoj TX pin nakon svakog pucnja i uopće ga ne zanima je li itko s druge strane primio taj podatak, niti mu treba mrežni status za nastavak rada.
Čemu onda služe ti povratni paketi ako uređaj radi i bez njih u čistoj jednosmjernoj vezi?
Na ovo je teško odgovoriti s obzirom da ne znamo sadržaj tih paketa. Razloga može biti više, a najizgledniji je mogućnost ažuriranja i kalibracije kronometra preko Wi-Fi veze. Moguće da se u nekom tvorničkom test procesu koristi ova bežična veza za slanje „servisnih“ naredbi koje vraćaju određene statuse MCU-a i drugog hardvera na pločici ili se upisuju kalibracijske konstante kod podešavanja uređaja.
Iako je stranica koju generira WiFi čip posve jednosmjerna (čisti statički prikaz bez mogućnosti izmjene ili klikanja podataka na prikazu), možda u naprednijim varijantama firmwarea (ili u Tuya aplikaciji) korisnik može mijenjati podatke na WiFi sučelju za što je onda potrebna dvosmjerna komunikacija sa MCU-om.
Kako god bilo, sve ovo ne odgovara na pitanje zašto i u našem konkretnom slučaju WiFi čip uvijek odgovara paketom od 10 bajta podataka, koja je svrha toga.
Drugo zanimljivo pitanje je zašto MCU šalje prema WiFi čipu sirove tikove, a ne već gotove izračune?
Činjenica je da MCU-u samostalno vrši sve izračune iz tikova brzine i prikazuje ih na LCD displeju. Kronometar može biti i u inačici bez WiFi čipa, tako da on MCU-u uopće nije potreban. Čini se malo nelogično da onda MCU na WiFi čip ne šalje gotove izračune, nego umjesto toga šalje sirove tikove brzine, te kalibar i masu projektila, na osnovu kojih WiFi čip mora ponovno napraviti sve te iste proračune da bi ih poslao na web preglednik.
Ne čini mi se izglednim da MCU nema dovoljno procesorske snage ili da bi paket podataka bio značajno veći da se umjesto tri podatka svaki veličine jedan ili dva bajta, šalje šest ili deset takvih podataka. Da se išlo na takvu uštedu, onda MCU ne bi svaki puta slao 10 zadnjih zapisa.
Razlog za ovo može biti u čistoj modularnosti i prilagodljivosti kronometra na različite periferne dodatke za prikaz, izračun, statistiku i memoriranje podataka. Kad takav sustav dobije sirove tikove brzine, te sirove podatke o kalibru i težini, on može iz toga vršiti bilo koje vlastite balističke izračune, sa bilo kojom točnosti. Nije ovisan o gotovom podatku koji računa MCU. Tako se na UART sabirnicu može vrlo lako spojiti bilo kakav MCU, Wi-Fi čip ili displej sa svojim prilagođenim softverom, a kronometar mu samo služi kao osnovni senzor brzine.
Tu činjenicu ću i ja iskoristiti za svoj projekt.
Osim ovoga, sirovi tikovi rješavaju još jedan potencijalni problem. Naime, na kronometru se mogu mijenjati mjerne jedinice m/s ili fps. Kad bi MCU za ove postavke na UART slao različite podatke (gotov izračun), morao bi u svom kodu čitati i HEX 69 te mijenjati formulu izračuna ovisno o odabranim mjernim jedinicama. Na sreću, MCU šalje uvijek jednak broj tikova pa tih problema nemam. CrowPanel mora uvijek dobivati podatak o brzini u jednakoj mjernoj jedinici kako bi znao dalje ispravno računati.
Sada kada smo pronašli registre gdje se spremaju tikovi trenutnog mjerenja brzine, mogućnosti za nadogradnju ovog kronometra HT-X3006 su vrlo široke. Hardverski to uopće nije loš kronometar, no WiFi podrška za mobitel je najblaže rečeno neupotrebljiva. Ugradnjom vlastitog WiFi čipa može se raditi fina kalibracija uređaja (u formuli za izračun brzine mijenja se konstanta 900 000 koja predstavlja razmak između optičkih senzora), a podaci se zatim mogu prikazivati na bilo kojoj platformi i bilo kojim protokolom. Može se napraviti aplikacija za mobitel, tablet ili neki MCU razvojni sustav s displejem. Takva aplikacija može uključivati broj zapisa koji je ograničen jedino kapacitetom memorije (praktično beskonačni broj zapisa) iz kojih se mogu vršiti svi potrebni izračuni, analize i statistike. Aplikacija može biti posve prilagođena podešavanju zračne puške u različitim profilima korištenja iste. Većina tvorničkih kronometara obično dolazi sa vrlo malim displejima koji prikazuju samo osnovne podatke.
Moja modifikacija uključuje zamjenu postojećeg WiFi modula ESP8266EX sa modernijim i boljim modulom XIAO ESP32-C6. Nakon toga slijedi programiranje ESP-NOW komunikacije sa balističkim kalkulatorom mojeg CrowPanela.
Ako se usporede konstrukcije kronometra HT-X3006 sa Voice opcijom i bez te opcije, jedinu hardversku razliku koju ćete primijetiti je mali zvučnik zalijepljen za WiFi modul na Voice verziji i pored njega SMD čip sa osam nožica, vjerojatno audio pojačalo (nema oznaka). S obzirom da nema posebnih zvučnih čipova, zvuk generira sam MCU RJM8L151 (isti MCU je na obje inačice).
Zvučnik na Voice inačici zalijepljen na WiFi modul.
Tiskana pločica i svi čipovi su jednaki na obje inačice, a razlika je samo što je kod Voice inačice dodan zvučnik i zalemljen mali čip u donjem lijevom kutu, odmah do lemnih točaka za zvučnik, koji je vjerojatno audio pojačalo.
Iz podataka o RJM8L151 može se vidjeti da je to jeftin i energetski štedljiv mikrokontroler (rad na bateriju), međutim, ima DAC (Digitalno-analogni pretvarač) ili brzi PWM koji mu omogućava osnovnu sintezu govora. MCU u svojoj Flash memoriji vrlo vjerojatno ima pohranjene vrlo komprimirane zvučne zapise (npr. snimljene brojke na engleskom ili kineskom “One”, “Two”, “Three”…). U prilog štednje memorije ide činjenica da se izgovaraju samo brojčane vrijednosti brzine i to u skraćenom obliku bez decimala. MCU te podatke šalje kroz svoj DAC ili PWM pin kako bi stvorio analogni audio signal.
Međutim, ovdje postoji i druga mogućnost. Puna oznaka MCU-a je Runjet RJM8L 151 / SC8T6 / L19 2347:
- RJM8L 151: Naziv serije (8-bitni, ultra-low-power, pojačana 8051 jezgra sa sigurnosnim kripto-koprocesorom).
- S: Označava podseriju sa specifičnim rasporedom periferije.
- C: Označava broj pinova kućišta. Slovo C stoji za 48 pinova (LQFP48 kućište).
- 8: Označava veličinu Flash memorije. U ovoj nomenklaturi broj 8 točno označava 64 KB Flash memorije (dok bi npr. oznaka B značila 128 KB).
- T: Označava vrstu kućišta (LQFP – Low-profile Quad Flat Package).
- 6: Označava industrijski temperaturni raspon rada (-40°C do +85°C).
- L19 2347: Interni tvornički kod serije proizvodnje (Lot code) i datum proizvodnje (47. tjedan 2023. godine).
MCU dakle dolazi sa svega 64 KB Flash programske memorije. Vrlo vjerojatno da sam firmware uređaja, grafika za LCD zaslon i upravljanje tajmerima troše većinu tih 64 KB memorije, te audio datoteke za glasovne najave fizički nikako ne stanu u tako malu memoriju.
To onda znači da su glasovni zapisi snimljeni na WiFi modul koji sadrži MCU ESP8266EX i vanjsku SPI Flash memoriju veličine 1 MB (BoyaMicro 25Q809). Moguće da su audio datoteke snimljene u toj memoriji. U prilog tome ide činjenica da ne možete kupiti inačicu kronometra koja ima samo Voice funkciju, bez da ima i WiFi funkciju.
Glavni MCU (Runjet RJM8L151) nikako ne može izravno čitati datoteke iz te BoyaMicro 25Q80 memorije dok je ona zalemljena na ESP8266EX. Razlog je taj što je SPI Flash memorija spojena na namjenske SPI pinove ESP8266 čipa preko kojih on učitava svoj operativni sustav i firmware. Kada bi Runjet pokušao pristupiti istoj memoriji preko istih vodova, došlo bi do električnog sukoba (sabirnički konflikt) i oba čipa bi se srušila. To znači da ako se zvučne datoteke doista nalaze u tom WiFi Flashu, onda ih reproducira ESP8266EX, a ne Runjet RJM8L151. Wifi modul je u tom slučaju ujedno i Voice modul.
Tvornički firmware za ESP8266 koji vrti Captive Portal i Tuya protokol zauzima možda oko 300 do 450 KB. To znači da ostaje preko 500 KB potpuno slobodnog prostora na Flash memoriji. Budući da su glasovne najave na ovakvim uređajima snimljene u niskoj frekvenciji (npr. 8 kHz ili 11 kHz, mono, 8-bit), jedna sekunda govora zauzima svega nekoliko kilobajta. Cijeli set brojeva od 0 do 9 mogu bez problema stati u 100-200 KB.
Ako WiFi modul radi i kao samostalan Voice modul (ESP8266EX iz čistih tikova sam računa brzinu koju onda može sam i „izgovoriti“), onda sve ovo i dalje ne objašnjava u potpunosti one „čudne“ komunikacijske bajtove Tuya protokola koje razmjenjuju Runjet RJM8L151 i ESP8266EX.
U konačnici, moguće da se zvuk uopće ne generira preko gotovih zvučnih zapisa. U industriji jeftinih kineskih uređaja koriste se razni načini sinteze govora. Vrlo popularna je tzv. Formantska sinteza govora – SAM (Software Automatic Mouth). Umjesto snimaka, algoritam matematički u realnom vremenu generira frekvencije ljudskog glasa (formante) kombiniranjem sinusnih valova i šuma. Ovo je iznimno resursno štedljiv način sinteze govora koji troši svega desetak kilobajta za cijeli program i može izgovoriti bilo koji broj ili riječ bez potrebe za Flash memorijom. Takav zvuk bi mogao generirati i Runjet RJM8L151, no čini mi se da je kvaliteta zvuka na ovom kronometru ipak nešto bolja nego to SAM sinteza može generirati.
Vidjeli smo na pločici kronometra dodatni čip sa osam nožica koji nema oznake. Postoje namjenski hardverski čipovi za sintezu govora – TTS (Text-to-Speech). ESP8266 ili Runjet bi preko obične UART veze ovom čipu mogao poslali sirovi tekst (ili specifične kodove za brojeve), a čip bi iz svog internog hardvera generirao savršen i čist govor izravno na zvučnik. Pa ipak, ova metoda se gotovo sigurno ne primjenjuje u našem kronometru jer čip sa samo 8 nožica (SOIC-8 kućište) fizički ima premalo pinova za kompleksnu komunikaciju i digitalno-analognu pretvorbu kakvu zahtijeva TTS sinteza. To je bez sumnje obično mono audio pojačalo klase D ili klase AB, koje služi isključivo kako bi slabašni zvučni signal s GPIO pina mikrokontrolera pojačalo do razine potrebne za pokretanje malog zvučnika.
Ovdje bi sada morao „brljaviti“ po pločici kronometra, odlemljivati veze WiFi čipa sa glavnim MCU i pratiti tiskane veze koje je izuzetno teško pratiti (crni lak) kako bi točnije izolirao mjesto na kojem se zapravo generira zvuk. U ovoj fazi ne želim uništiti ova dva primjerka kronometra koje imam jer mi je prioritet njihovo spajanje na CrowPanel u smislu prijenosa tickova brzine. Na kraju, već i moj CrowPanel ima zvučne najave u puno boljoj kvaliteti, tako da ova sa kronometra i nije nužno potrebna.
Preko XIAO ESP32-C6 i ESP-NOW veze svakako na CrowPanel šaljem sirove tickove, jer na CrowPanelu želim funkciju koja omogućuje jednostavnu korisničku kalibraciju oba kronometra (na ustima cijevi i na meti) promjenom konstanti kronometara u izračunu brzine iz tikova.
Kronometar HT-X3006 se bez kućišta lako „raspada“ i općenito je teško trigerirati senzore na radnom stolu u svrhu testova, pogotovo sa velikom brzinom. U ovoj fazi se trudim ne „mrcvariti“ čitav sklop više nego je to nužno potrebno.