Öfugt verkfræðingar verkefni. Það hófst með Bowflex Treadmill 22 en þróaðist síðan almennt fyrir hvaða Android-stýrða tæki sem Nautilus Inc. selur (Nautilus, Bowflex, Schwinn).
Þetta á sér stað aðallega við Treadmill 22 og Treadmill 56.
Stýritaflan umherjunar er framleidd af Electronics Way Industry.
Með þjónustubóklega handbækinni sem Nautilus Inc. veitir (afrit á archive.org):
Sérstaklega einbeitt mér þessu hluta:
Við getum greint “tengingarsvélina” sem tengir stýritafluna sem 5-pinna kavli. Það er aðeins einn 5-pinna tenging.
Ég hef merkt síðan kvällarnar með viðeigandi litum (gögn & skift eru opto-eiginlaus):
Litur köku | Merking |
---|---|
rauður | GND |
hvítt | RXD |
svartur | TXD |
guli | +12 |
grænn | SW |
Taflan er ekki bein tengd við Android stýrikerfið.
Einungis 5-pinna tengingin er frá Molex. Google leit eftir “smáir Molex tengingar” leiddi mig að mynd af því sem þeir kalla Molex Micro-Fit 3.0 Single Row (5-Pin)
, sem er notað til að tengja stýritafluna:
Með því að skoða NautilusLauncher.apk
í gegnum jadx-gui
, get ég séð að þeir tengja Android spjaldtölvuna við sína “Universal Console” með seríu við 230400 Baud (með /dev/ttyS4
). ÞEITTA er EKKI það sem við erum að greina hér. Það vísaði til samskipta milli Android og “Universal Console”. Við erum að rannsaka samskipti milli “Button Panel Controller” og “Motor Controller Board”, sem útilokar þrjár spjald sem möguleg bilunarpunkt.
Að reyna að tengja ESP32 eða CH340-byggðan seríubryggju beint við köflurnar milli bandvélgrunnsins og Bowflex stjórntaflunar tækninnar olli því að bandvélin wedstrættist ekki rétt, eftir sem ég fékk logic analyzer til að rannsaka frekar.
Undanfarnar vikur, og næstum þremur árum eftir að ég byrjaði á þessu, hafa nokkrir aðilar leitað til mín og beðið um framvindu í þessu, sem staðfestir upphaflega tilgátu mína um að hlaupabrettakerfið sé hræðilegt og það væri bara tímaspursmál hvenær vélar fóru að bila. Það virtist vera góður tími til að taka rökgreiningartækið mitt, sem hingað til hafði aðeins safnað ryki, í notkun.
Að tengja logic analyzer við TXD og RXD línurnar (og GND, auðvitað), gat ég tafarlaust byrjað að grípa við skilaboð milli báðum aðilanna án þess að trufla samskiptin. Ég geri ráð fyrir að ég gat upphaflega ekki notað ESP32 vegna mótstöðu vandamála. Eftir nokkurra mínúta af tilraun og mistök kom ég að eftirfarandi seríusstillingu:
- 2400 Baud
- 8 bita á rampu
- 1 stoppa bit
- Engin athafna bit
- Einstaklingsnæstur bit sendur fyrst
- TXD: Afgert merki
- RXD: Ekki afgert merki
Með þessum stillingum gat ég greinilega séð skilgreind skilaboð.
Grípa við UART skilaboð meðan á upphafi ferlisins stendur
Nokkrir hlutir sem ég tók strax eftir:
0x68
0x73
0x43
Með því sem grunn getur ferlið við að þýða skilaboðin og skilja hvað er verið að miðla milli báðum aðilanna hafist, sem gerir stjórnað breiti í æfingaráætlun.
Með því að gera stjórnaðar breytingar á ákveðnum hraða, má sjá eftirfarandi gildi send til stýritaflu umherjunar:
Hraði á skjánum | Skilaboð sem send eru |
---|---|
0.0 km/h (bíða eða stöðva) | 0x68 0x08 0x80 0x50 0x00 0x0A 0x00 0x00 0xE2 0x43 |
2.0 km/h | 0x68 0x08 0x80 0x50 0x14 0x0A 0x00 0x00 0xF6 0x43 |
3.0 km/h | 0x68 0x08 0x80 0x50 0x1D 0x0A 0x00 0x00 0xFF 0x43 |
5.0 km/h | 0x68 0x08 0x80 0x50 0x31 0x0A 0x00 0x00 0x13 0x43 |
Má sjá að báti 5 og báti 9 breytast. Báti 5 virðist vera hraðinn í sextán tear, og báti 9 virðist vera heilstöðugjókvarði.
Umbreyting gildis báts 5 í tugatekju:
Hraði á skjánum | Sextán Reykjavíkur | Tugi |
---|---|---|
0.0 km/h (bíða eða stöðva) | 0x00 | 0 |
2.0 km/h | 0x14 | 20 |
3.0 km/h | 0x1D | 29 |
5.0 km/h | 0x31 | 49 |
Eftir því sem ég aflaði nokkurra hluta Android kerfisins á árum síðustu, man ég eftir því þegar stilltum kerfið á mælieiningunni, Bowflex forritið framkvæmir innri umbreytingu frá mælieiningunni til imperíusk til að samskiptast við “UCB”. Stýritaflan umherjunar virðist nota mælieininguna og skv. því er tapað nákvæmni í umbreytingunni frá mælieiningunni til imperíusk og síðan aftur til mælieiningunnar (sem það sem stýritaflan umherjunar horfir til), þar sem allt er með 1 decimal nákvæmni. Var það svo erfitt að gera það rétt, Nautilus?
Að hugsa slíkt og, ef stækkunarstuðull 10 er beittur, passar það fullkomlega við gildin sem send eru til stýritaflu umherjunar. Þannig að formúlan yrði:
Tugi gildi = Hraði í km/h × 10
Með því að fylgja sömu ferlinu og með hraða má sjá eftirfarandi gildi send til stýritaflu umherjunar:
Halla á skjánum | Skilaboð sem send eru |
---|---|
-5° | 0x68 0x08 0x80 0x50 0x1D 0x00 0x00 0x00 0xF5 0x43 |
0° | 0x68 0x08 0x80 0x50 0x1D 0x32 0x00 0x00 0x27 0x43 |
9° | 0x68 0x08 0x80 0x50 0x1D 0x8C 0x00 0x00 0x81 0x43 |
Í þessu tilfelli virðist báti 6 vera halla í sextán tear, og það staðfestir að báti 9 er heilstöðugjökvarði.
Umbreyting gildis báts 6 í tugatekju:
Halla á skjánum | Sextán Reykjavíkur | Tugi |
---|---|---|
-5° | 0x00 | 0 |
0° | 0x32 | 50 |
9° | 0x8C | 140 |
Formúlan sem passar fullkomlega við gildin sem send eru til stýritaflu umherjunar er:
Tugi gildi = (Horn + 5) × 10
Þetta virðist vera einfaldur og staðlaður heilstöðugjökvarði í örstjórntölvum, þar sem öll bitskilaboð skilgreint og valda yfirbreytingu þegar það nær 256. Einföld framsetning væri eitthvað eins og:
uint8_t reiknaHeilstodugjokkvardi(uint8_t *skilabo)
{
return skilabo[1] + skilabo[2] + skilabo[3] + skilabo[4] + skilabo[5] + skilabo[6] + skilabo[7];
}
Með því að nota uint8_t
sem skilyrði, fer yfirbreytingin af náttúrulegu. for loop
gæti verið notað til að leggja gildin saman og skila sum % 256
, en það væri hægara fyrir örstjórntölvur án raunverulegs ávinnings.
Með því getur virkni hnappapöllunnar verið endurtekinn, og með því getur bandvélin verið stjórnað frá örstjórntölvu.
— Til að vera áfram —
©2022-2025 Sebastián Barrenechea. Öll réttindi áskilin.
Búið til með Astro v5.6.1.