what we have here is failure to communicate (nrf24l01?)

[sid (Gast)]

Mahlzeit,

irgendwie kratze ich mir gerade ein mittelgroßes Loch in die 
Kopfbehaarung,
und würde gerne mal einige Meinungen von Euch hören bevor ich zu Gewalt 
übergehe.

Die Situation:
Ich habe mir ein elektrisches Skateboard gekauft vor ein paar jahren 
(naja ein Motorset zum Anschrauben.. funing.. ich mag's)
Der Support war ehrlich ausgezeichnet, aber scheinbar hat die Firma 
Funing Tech das zeitliche gesegnet und ich habe damit auch jeden Kontakt 
zu deren Support verloren leider.

Das Problem:
Die Ferbnbedienung kann seit einiger Zeit den Motorcontroller nichtmehr 
erkennen, sie blinkt auf der Suche nach Kontakt und die Motoren drehen 
sich nur ... na sagen wir stotternd, der Motorcontroller scheint also 
die Fernbedienung noch zu erkennen.

Die Hardware:
die Fernbedienung nutzt ein AS01-SPIPX Funkmodul (mit *nRF24L01+* 
Chip)
das auf das PCB gelötet ist und von einem STC15W408AS via SPI 
kontrolliert wird.
der Motorcontroller ist vollständig vergossen und sein externes 
Funkmodul
würde etwas Gewalt erfordern um auch nur die Beschriftung lesen zu 
können,
das würde ich also lieber ersteinmal unangetastet lassen.
Da es aber nur 5 zuleitungs Kabel hat (zwei davon seperat: rot/schwarz)
würde ich SPI hier als unwahrscheinlich einstufen, da es aber kein 
bare-copper gibt und jeder elektrisch leitende Test eine teilweise 
Zerstörung bedarf.. hab ich alles Weitere ersteinmal ignoriert.
Anzunehmen ist aber, dass es was Shockburst kompatibles ist n nRF2401A 
vllt
oder auch n nRF24L01+ mit ner uart bridge ... wenn nicht anders geht 
guck ich nach.

mein Ansatz:
mangels wohlausgestatteter Elektronikwerkstatt,
musste ich ein wenig "kreativ werden" und ja, das ist ein Euphemismus 
für "rumprutschen" :D

Ich hab also ein altes Kabel aus der Krimskramkiste gezogen das einen 
0.05" Stecker hatte,
den Stecker mit ein paar abgeschnittenen Bauteilbeinchen zum männlichen 
Pendant umoperiert,
das andere Ende in mein Steckbrett genagelt
und mit nem Arduino versucht die SPI Kommunikation 'mitzuhören', wenn 
die Fernbedienung startet.
und ich konnte nichtnur das Setup des Funkmoduls mitansehen sowie das 
versenden einiger payloads, sondern nach ein paar Versuchen und dem 
Abwarten einer ruhigen Sekunde auch dessen Register vollständig und 
fehlerfrei auslesen.
MOSI log (mit erklärung):

0x30  0x24 0xA0 0x15 0x03 0xBB  |0x30 => W_REGISTER TX_ADDR    5 bytes (address: 0xBB0315A024)
0x2A  0xFF 0xFF 0xFF 0xFF 0xFF  |0x2A => W_REGISTER RX_ADDR_P0 5 bytes (address: 0xFFFFFFFFFF)
0x21  0x00                      |0x21 => W_REGISTER EN_AA      1 byte  (disable auto ack)
0x22  0x01                      |0x22 => W_REGISTER EN_RXADDR  1 byte  (enable only data pipe 0)
0x25  0x00                      |0x25 => W_REGISTER RF_CH      1 byte  (channel set to 0 [2.4GHz])
0x31  0x0A                      |0x31 => W_REGISTER RX_PW_P0   1 byte  (payload set to 10 bytes)
0x26  0x07                      |0x26 => W_REGISTER RF_SETUP   1 byte  (power 0dBm, 1Mbps data rate)
0x30  0x24 0xA0 0x15 0x03 0xBB  |0x30 => W_REGISTER TX_ADDR    5 bytes
0x20  0x3F                      |0x20 => W_REGISTER CONFIG     1 byte  (IRQ:RX_DR, CRC16, PW_UP, PRX)
0x07  0x00                      |0x07 => R_REGISTER STATUS     1 byte
0x27  0x0E                      |0x27 => W_REGISTER STATUS     1 byte  (reset value 0x0E)

REPEAT:
0x2A  0xFF 0xFF 0xFF 0xFF 0xFF  |0x2A => W_REGISTER RX_ADDR_P0 5 bytes
0xA0  0x01 0x91 0x00 0x00 0xFF  |0xA0 => W_TX_PAYLOAD         10 bytes (only throttleposition?)
      0xFF 0x00 0x00 0x00 0x00  | // leftmost 16bit change according to throttle position //
0x20  0x7E                      |0x20 => W_REGISTER CONFIG     1 byte  (IRQ:--, CRC16, POWER_UP, PTX)
0x20  0x3F                      |0x20 => W_REGISTER CONFIG     1 byte  (IRQ:RX_DR, CRC16, PW_UP, PRX)
::

nRF24L01+ Register

reg#   data     (reg#   data)
0x00   0x3F    | 0x01   0x00 
0x02   0x01    | 0x03   0x03 
0x04   0x03    | 0x05   0x00 
0x06   0x07    | 0x07   0x2E
0x08   0x00    | 0x09   0x00 

0x0A   0xFF 0xFF 0xFF 0xFF 0xFF 
0x0B   0xC2 0xC2 0xC2 0xC2 0xC2

0x0C   0xC3    | 0x0D   0xC4 
0x0E   0xC5    | 0x0F   0xC6 

0x10   0x24 0xA0 0x15 0x03 0xBB 

0x11   0x0A    | 0x12   0x0A 
0x13   0x00    | 0x14   0x00 
0x15   0x00    | 0x16   0x00 
0x17   0x11 
0x1C   0x00    | 0x1D   0x00

Soweit so gut!
Ich weiss also, Shockburst (NICHT enhanced shockburst) kenne den 
Funkkanal und die Addressen, CRC einstellung usw.

Also ab an die brasilianische Flussmündung und n paar dieser billigen 
nrf24L01 Dinger gekauft, schon der zweite versuch brachte mir Modelle 
ein die zwar immernoch gefälscht aber mindestens funktionstüchtig sind
(das alleine hat 14 Tage gedauert)
egal.. waren billig und zum Testen muss das reichen

dei Payloads der Fernbedienung sind zum Glück unfassbar trivial:
"xx xx 00 00 FF FF 00 00 00 00"
wobei xx xx nichts als die 10bit des ADC sind der das "Gaspedal" 
ausliesst.
mittelt sich bei 0x191 ein (nicht perfekt, aber zuverlässig)
höchster wert 0x3e8 oder so (auch nicht perfekt aber okay)
und der microcontroller rundet starkes bremsen auf perfektes 0x0000
der Rest scheint mir bislang vollends unmodifizierbar.

Ich hab also mit meinem Modul ein paar ähnlich gestrickter payloads an 
den Controller geschickt und es funktioniert.. gut gut
Ich versuchte natürlich auch die RX Addresse der Fernbedienung zu 
belauschen, hörte aber nie irgendetwas..
(die unfassbar dämliche Addresse ist "FF FF FF FF FF" na suuuper)
Also hab ich CRC deaktiviert und siehe da.. NOISE
unfassbar viel Krach (was zu erwarten war mitten im Wlan Band)
seltenst mal ein 0bit.. also fielen mir ausreisser nach unten schnell 
auf..
nach so 10Mb and mitgeschnittenem Käse kristallisierten sich einige
10 byte Pakete auf, die ich nur sah, wenn der Motorcontroller auch 
angeschaltet war
(mitschnitte fast immer über die ganzen 32 möglichen bytes.. und nie war 
da eine CRC Prüfsumme dahinter, häufig was was so aussah als wenn nach 
15 byte eine käme.. aber sie passt nicht.)
Also vermutete ich mal die 10byte die die Fernbedienung auch erwartete.
die folgenden Kandidaten hatten sich in dem Lärm herausgefiltert:

0xE8 0xF2 0x40 0x29 0x70    0x10 0x10   0x24 0x50 0x00 
0xA3 0xC9 0x00 0xA5 0xC0    0x40 0x40   0x91 0x40 0x00 
0xF4 0x79 0x20 0x14 0xB8    0x08 0x08   0x12 0x28 0x00

die ersten fünf byte sind immer unverändert, mal ein falsches bit hier, 
mal eins da.. aber im Grunde diese ...
Die TX Addresse der Fernbedienung ist ähnlich "willkürlich" ich würde 
also vermuten, dass das ein Paarungsversuch des Motorcontrollers 
darstellt mit der Bitte um Addressanpassung
die folgenden Zwillinge sind ebenso unverändert,
sie erinnerten mich and das 0xFF 0xFF ich vermute Sinnhaftigkeit in 
deren Wert, allein der Sinn erschliesst sich mir noch nicht.

die letzten drei Byte sind quasi variabel.. immer mal wieder ändert sich 
das mittlere byte, dann steigt es wieder (in 0x10 er Schritten)

Ich hab also mit den CRC Einstellungen gespielt.
der Motorcontroller braucht ZWINGEND eine 2 byte CRC damit er die 
Befehle der Fernbedienung (und meines Replikats) anerkennt.. er sendet 
aber im Gegenzug scheinbar OHNE CRC Prüfsumme.
Wissend, dass die Fernbedienung im RX Modus aber eine Prüfsumme 
erwartet, hab ich mir einen Papageien gebastelt, der zehn bytes ohne 
Prüfsumme liesst, und dann mit Prüfsumme an dieselbe Addresse schickt.
und sihe da... die Fernbedienung meint den Motorcontroller zu sehen, 
hört auf zu blinken und zeigt volle Batterieleistung an (könnte sogar 
gut sein.. hatte sie ja frisch geladen als mir das Problem auffiel)

In der Sekunde wo ich den Papageien abschalte fängt die Fernbedienung 
wieder an zu suchen...
irgendwas von meinen Annahmen muss also ausreichend zutreffen.

Aber: die FB wechselt ihre Addresse nicht (sonst würde ich sie im 
Funkprotokoll an der alten Addresse ja nichtmehr sehen können)
der Motorcontroller auch nicht.
Und wieso der Motorcontroller sich quasi von jetzt auf gleich weigert 
eine Prüfsumme zu erstellen für seine versendeten Pakete ist mir 
schleierhaft.
Ich behauptete mal frech, dass dieselbe Hardwareimplementierung das 
einkommende und das ausgehende Paket bespielt in diesen kleinen Dingern

Ich hab einfach keine Idee, weswegen der Motorcontroller aufgehört hat 
CRC Sumnmen zu senden, das Pfund Epoxid macht es mir auch nicht leicht 
den Fehler einzugrenzen.

Nun (ENDLICH!!) die Frage:
Habt Ihr eine Idee was entweder dazu führt, dass der microcontroller 
ein/zwei bits in einem Befehl vergisst
oder was das Funkmodul dazu bringt keine CRCs mehr erstellen zu können 
sie aber dennoch interpretieren und prüfen kann für einkommende Pakete?

Wenn ihr ne Idee habt wie die Pakete des Motorcontrollers zu deuten 
sind,
bin ich auch glücklich über Eure Nachricht,
irgendein Fernsteuerdingen (Drone, Skateboard, Auto.. vllt auch nur ein 
gamecontroller oder sowas 2.4Ghziges) könnte ja ein Protokoll benutzen, 
dass mindestens so ähnlich ist, dass man es mal zur Weitererforschung 
heranziehen kann.

Wie gesagt, ich bin echt nicht scharf drauf mit dem großen 
Schraubendreher in dem Motorcontroller herumzuhebeln um an das Funkmodul 
zu kommen, solange ihr also Alternativen habt wär ich froh.

Dankeschön

'sid