Fremdes Register per SPI auslesen möglich?

[Leon333]

Hallo,

ich habe hier einen Funk-Empfänger, der mir aber leider seine Signalqualität (RSSI) nicht ausgibt.
Es handelt sich dabei um einen A7105

Auf Seite 76 des Datasheets, steht, dass die RSSI-Werte im 1Dh Register (ADC [7:0]) abgelegt sind.
Mein Nano ist momentan über den MOSI Pin (D11) am SDIO des A7105
und mit SCK (D13) and SCK des A7105. (Jeweils mit 470 Ohm Widerstand)

Theoretisch könnte ich auch noch an den SCS Pin des A7105, allerdings muss ich erstmal wissen ob ich so überhaupt an mein Ziel kommen kann.
Momentan lausche ich nur an SDIO und lasse mir von SCK den Takt geben.
Dort gibt der A7105 verschiedene Werte an einen anderen Chip weiter.

Ist es möglich auf das genannte Register zuzugreifen und die Werte von dort zu erhalten?

[pylon]

Wenn ich Dich richtig verstehe, hast Du Deinen Nano an einen Chip im Funkempfänger angeschlossen. Laut Dokumentation wird dieser mit 3.3V betrieben, die I/O-Pins vertragen bis 3.9V. Wenn Du den Chip also mit den 5V des Nano belieferst, wirst Du die Lebenserwartung trotz des Widerstands (der bestenfalls den Strom etwas begrenzt) herunterschrauben und möglicherweise andere Chips im Gerät dauerhaft beschädigen (falls diese noch heikler reagieren). Ich würde also zumindest einen Level-Converter dazwischen schalten, dieser sollte aber Tri-State fähig sein, damit der SPI-Bus nicht komplett blockiert wird. Überhaupt dürfte das Ansteuern des Chips über den Bus heikel sein, da ja wahrscheinlich der interne Controller auch über diesen Bus mit dem Chip kommunizeren dürfte.

Damit Du mit dem Chip kommunizieren kannst, müsstest Du den SDIO-Pin des Empfängers mit MISO und MOSI verbinden (Du willst ja senden können und Daten empfangen). Da dies von der ATmega328-Hardware nicht vorgesehen ist, würde ich die Hardware-SPI-Schnittstelle weglassen und per Software-Emulation die Daten auslesen. Dann kannst Du den Daten-Pin auf Arduino-Seite zur richtigen Zeit auf Aus- oder Eingang umschalten.

Der Chip unterstützt auch 4-Draht-SPI, allerdings weiss ich nicht, ob das die Kommunikation mit den anderen Chips durcheinander bringen könnte. Falls das nicht so sein sollte, könntest Du Deine Beschaltung belassen (mit Level-Converter) und GIO1 an MISO anschliessen.

Für Dein Register wäre dann die folgende Sequenz möglich:

SPI.transfer(0x5d); // read 0x1d register
byte value = SPI.transfer(0x00); // read the value

[Leon333]

Ja das hast du so richtig verstanden pylon.

Der Hinweis mit den unterschiedlichen Logic-Levels ist natürlich richtig. Einenen Bidirektionalen LL-Converter habe ich aber hier und könnte da also theoretisch dran - das war bisher allerdings aufgrund des nur "zuhörens" nicht nötig.
Was die Tri-Stats angeht, das kenne ich noch nicht mal und finde dazu auch nicht besonders viel Information.
Ich habe diese Converter Variante 1 und Variante 2.

Der Rest deines Beitrags ist noch schwieriger zu verstehen
Also es gibt deiner Meinung nach 2 Möglichkeiten:

1. "irgendwie" per Software-Emulation am SDIO zwischen Ausgang und Eingang umschalten um an diesem Pin mal die Daten mitzulesen und mal zu schreiben.
   An dem SDIO ist noch ein anderer Chip angeschlossen ein TG13426 Bild.
   Den brauche ich im Prinzip nicht, da diser nur ein PWM Signal für nicht besetzte Ausgänge generiert.
   Dennoch ist die Frage ob ich hier überhaupt "dazwischenfunken" kann oder damit die Kommunikation komplett einbricht.
   Und Abschließend natürlich auch noch, wie man so eine Softwareemulierte SPI Schnittstelle bekommt, weil librarys gibt es dafür nicht

2. Der GIO1 (Pin16 des A7105) ist mit nichts verbunden, das ich ausfindig machen könnte.
   Das ist allerdings auch ein Problem, weil ich hier an ein ~200µm breites Beinchen löten muss :o :o
   Abgsehen davon hab ich quasi auch kein Platz mehr um einen Level-Converter später einzubauen (das ist aber erstmal das geringste Problem).

Es reicht also, wenn ich GIO1 (Pin16 vom A7105) mit MISO (Pin12 vom Arduino Nano) verbinde und dann einfach deinen Code ausführe?
Ich werde das nach deiner Rückmeldung dann mal probieren.
Außerdem habe ich mir jetzt ein 100MHz Oszilloskop gekauft um da mal genauer lauschen zu können.

[pylon]

Den brauche ich im Prinzip nicht, da diser nur ein PWM Signal für nicht besetzte Ausgänge generiert.

Dann würde ich ihn ggfs. auslöten.

Und Abschließend natürlich auch noch, wie man so eine Softwareemulierte SPI Schnittstelle bekommt, weil librarys gibt es dafür nicht

Das ist nicht umwerfend schwer, Du generierst ein Clock-Signal, indem Du abwechselnd ein HIGH und ein LOW auf einem Ausgang ausgibst. Beim Schreiben setzt Du den Daten-Ausgang entsprechend dem Bit-Wert, den Du schreiben willst, bevor Du den Übergang von LOW nach HIGH machst. Wenn Du liest, darfst Du das erst machen, wenn das Clock-Signal bereits auf HIGH steht.

Es reicht also, wenn ich GIO1 (Pin16 vom A7105) mit MISO (Pin12 vom Arduino Nano) verbinde und dann einfach deinen Code ausführe?

Nein, denn dann kriegt der Chip kein Clock-Signal. Zudem musst Du ihm ja erst sagen, was Du lesen willst. Und dafür musst Du auch schreibend auf das Teil zugreifen können, was wiederum ohne Level-Converter für den Chip tödlich ausgehen kann.

Wenn Du den anderen Controller auslötest (somit also nur noch der Chips selbst mit den SPI-Pins verbunden ist), kannst Du einen normalen Level-Converter nehmen (wie den von Sparkfun, das andere China-Teil hat keine Schemas dabei, also Finger weg, ausser Du machst Dir die Mühe, das Ding zu reverse-engineeren), um den Empfänger mit dem Nano zu verbinden. Das Umschalten in den 4-Draht-Modus ist ja nur schreibend, also genügt dafür die SDIO-Verbindung an MOSI (immer über den LC).

Außerdem habe ich mir jetzt ein 100MHz Oszilloskop gekauft um da mal genauer lauschen zu können.

Das brauchst Du hoffentlich noch nicht, aber so ein Ding ist immer gut :-).

[Leon333]

Beim Anschluss an GIO1 (Pin16) meine ich natürlich (alles per LLC) mit gleichzeitig verbundenem SCK und MOSI an den Pins 12(SCK) und 14 (SDIO) des A7105.

Das Auslöten des TG13426 würde ich gerne vermeiden, da ich dafür nicht das geeignete Werkzeug habe und nicht weiß, ob ich vielleicht später wieder in den Urzustand will

Ich verstehe das mit dem 3PIN SPI nicht so richtig. (auch nicht mit dessen Diagramm)
An dem SDIO gibt der Daten aus und liest auch ein , wenn SCS LOW ist.
Wie koordiert man denn dann wann Daten rein gehen, wenn vielleicht gerade etwas gesendet wird?
Ich hab mich jetzt noch nicht per LA oder Oszilloskop dran gehangen (ist auch noch nicht da), aber ich vermute, dass der A7105 ohne Rückmeldung vom TG13426 immer fröhlich die Kanal-Werte schreibt und dieser einfach die einzelnen PWM-Kanäle generiert.
Theoretisch müsste es doch auch möglich sein das Arduino dazu zu bringen dort zu lauschen und wenn die Übertragung beendet ist, dem A7105 zu sagen, dass man die RSSI-Werte haben will, er sie ausgibt und dann wieder die Kanal-Werte ausgibt oder?
Oder fragt der TG13426 ständig die Werte an? Falls dem so wäre, dann kann ich ihn sowieso nicht auslöten.
Momentan bastel ich mir aus den gelesenen Werten nämlich ein SBUS-Signal für meine Flugsteuerung zusammen.

Falls du, @pylon, zur Beantwortung oder Analyse irgendwelche Messdaten von mir brauchst (das oszilloskop hat nur 2 Kanäle aber einen LA von Salaea habe ich hier), dann sag es mir und ich werde mein Bestes geben, dir dabei zu helfen, mir zu helfen

[pylon]

Ich hab mich jetzt noch nicht per LA oder Oszilloskop dran gehangen (ist auch noch nicht da), aber ich vermute, dass der A7105 ohne Rückmeldung vom TG13426 immer fröhlich die Kanal-Werte schreibt und dieser einfach die einzelnen PWM-Kanäle generiert.

Ich vermute, dass Du damit falsch liegst. Ich gehe davon aus, dass der MC die Werte explizit abfragt und dafür auch das notwendige Clock-Signal bereitstellt.

Theoretisch müsste es doch auch möglich sein das Arduino dazu zu bringen dort zu lauschen und wenn die Übertragung beendet ist, dem A7105 zu sagen, dass man die RSSI-Werte haben will, er sie ausgibt und dann wieder die Kanal-Werte ausgibt oder?

Theoretisch ist ein Lauschen möglich, allerdings kannst Du dann nur lauschen und nicht in den Prozess eingreifen, d.h. andere Werte auslesen als der eingebaute MC schon liest. Auch ist der Anschluss des Arduinos parallel zum bestehenden MC gefährlich, weil ein SPI-Bus keine zwei Bus-Master verträgt.

Oder fragt der TG13426 ständig die Werte an? Falls dem so wäre, dann kann ich ihn sowieso nicht auslöten.
Momentan bastel ich mir aus den gelesenen Werten nämlich ein SBUS-Signal für meine Flugsteuerung zusammen.

Wieso kannst Du ihn dann nicht auslöten? Du kannst die gleichen Werte ja auch abfragen, einfach aktiv und nicht nur passiv, wie Du das jetzt machst.

Falls du, @pylon, zur Beantwortung oder Analyse irgendwelche Messdaten von mir brauchst (das oszilloskop hat nur 2 Kanäle aber einen LA von Salaea habe ich hier), dann sag es mir und ich werde mein Bestes geben, dir dabei zu helfen, mir zu helfen

Ich würde den LA mal an SCS, SCK, SDIO und GIO1 hängen und nach einer fallenden Flanke an SCS einige Millisekunden aufzeichnen. Falls Du weisst wie, würde ich den Saleae so einstellen, dass er die SPI-Daten gleich analysiert. Poste dann das Resultat als CSV-Datei oder Screenshot der ersten paar Byte Signale.

[Leon333]

DHL hat mein Oszilloskop leider fehlgeleitet, es kommt daher erst übermorgen -.-

Naja, die Lötarbeit habe ich aber erledigt und mal den LA dran gehangen.
Das SPI Signal muss ich mit mindestens 2MHz auslesen, sonst gehen Pegel verloren.

Hier mal ein Screenshot von einem mit 12MHz mitgeschnittenem Verlauf, wenn die Fernbedienung aus ist.
Und danach habe ich einen Screenshot gemacht, wenn die Fernbedienung an ist.

Die Eingänge habe ich alle entsprechend des A7105 bezeichnet.
RSSI habe ich mal mit dran gehangen, aber ich bin mir sicher, dass ich da mal eher mit einem Oszilloskop dran muss um zu sehen, was genau da passiert.

Wie man sieht fällt SCS mehrmals auf GND/LOW/0.
Das kommt daher, dass da mehrmals hin und her gesendet wird, zwischen dem A7105 und dem Demultiplexer.
Das kann man auch daran erkennen, dass der Takt/SCK in der Zeit aufhört, wenn SCS High/1 ist.
GIO1 ist die komplette Zeit über 0.

Ich werde mal ab Fallender Flanke bei GIO1 mitschneiden und versuchen den Mitschnitt zu analysieren...

EDIT:
Beim Analysieren verlangt das SPI Protokoll MOSI, MISO, Clock und Enable.
Da wir aber hier ja nur ein 3-wire-SPI haben, habe ich MISO mal ausgeschaltet und das was dabei rausgekommen ist, habe ich als Bild angehangen.

[Leon333]

Sooo....

also ich ich jetzt die 8 Kanäle mal den Minmalwert, die Nullstellung und den Maximalwert von der Fernbediehnung senden lassen.

Dabei sind folgende Mitschnitte entstanden wobei ich immer eine neue Zeile mache, wenn SCS wieder HIGH ging. (grün und blau sind die Kanalwerte)

Fernbedienung aus:
4 TAKTE aber kein auslesbarer Wert.. hier ist SDIO HIGH,LOW,HIGH,LOW
4 TAKTE aber kein auslesbarer Wert.. hier ist SDIO HIGH,HIGH,HIGH,HIGH
15, 100
4 TAKTE aber kein auslesbarer Wert.. hier ist SDIO HIGH,HIGH,LOW,LOW

Fernbedienung an, alle 8 Kanäle auf MIN
64, 24
69, 85, 223, 184, 1, 0, 223, 3, 224, 3, 223, 3, 224, 3, 223, 3, 224, 3, 223, 3, 223, 3,
4 TAKTE aber kein auslesbarer Wert.. hier ist SDIO HIGH,LOW,HIGH,LOW
4 TAKTE aber kein auslesbarer Wert.. hier ist SDIO HIGH,HIGH,HIGH,HIGH
15, 100
4 TAKTE aber kein auslesbarer Wert.. hier ist SDIO HIGH,HIGH,LOW,LOW

Fernbedienung an, alle 8 Kanäle auf Mitte:
64, 24
69, 85, 223, 184, 1, 0, 224, 5, 224, 5, 225, 5, 224, 5, 224, 5, 225, 5, 225, 5, 224, 5,
4 TAKTE aber kein auslesbarer Wert.. hier ist SDIO HIGH,LOW,HIGH,LOW
4 TAKTE aber kein auslesbarer Wert.. hier ist SDIO HIGH,HIGH,HIGH,HIGH
15, 100
4 TAKTE aber kein auslesbarer Wert.. hier ist SDIO HIGH,HIGH,LOW,LOW

Fernbedienung an, alle 8 Kanäle auf Max:
64, 24
69, 85, 223, 184, 1, 0, 225, 7, 226, 7, 226, 7, 226, 7, 226, 7, 226, 7, 225, 7, 225, 7,
4 TAKTE aber kein auslesbarer Wert.. hier ist SDIO HIGH,LOW,HIGH,
4 TAKTE aber kein auslesbarer Wert.. hier ist SDIO HIGH,HIGH,HIGH,HIGH
15, 100
4 TAKTE aber kein auslesbarer Wert.. hier ist SDIO HIGH,HIGH,LOW,LOW

Der letzte lesbare Wert (die 100) ist dabei immer ein anderer und immer zwischen 0 und 150 und ein vielfaches von 10... vielleicht eine Checksumme oder so?

Ich stelle das SPI mal auf 4bit pro Transfer um, wobei ich nicht weiß ob uns das hier wirklich was hilft (aber so ist zumindest alles mal ausgewertet..)

[Leon333]

4bit Auswertung:

Funke aus:
10
15
0, 15, VARIABEL, VARIABEL
12

Funke an, alles MIN (grün und blau sind die Kanalwerte):
4, 0, 1, 8
4, 5, 5, 5, 13, 15, 11, 8, 0, 1, 0, 0, 13, 15, 0, 3, 14, 0, 0, 3, 13, 15, 0, 3, 14, 0, 0, 3, 14, 0, 0, 3, 13, 15, 0, 3, 14, 0, 0, 3, 13, 15, 0, 3
10
15
0, 15, VARIABEL, VARIABEL
12

Wegen dem 3-Wire-SPI ist man hier leider etwas blind, was jetzt von welchem Chip kommt.
Klar ist für mich nur, dass die Sequenz mit den Kanal-Werten vom A7105 kommt.

Wenn die Fernbedienung an ist, dann leuchtet die Diode (rot markiert im Bild) die zum FT24C002A führt.
Der FT24C02A ist ein Two-Wire Serial EEPROM, dessen GND, A0-A2 und WP auf GND liegen.
Ein Schaltbild davon findet man auch hier.

Den Demultiplexer hab ich nun auch ENDLICH gefunden oder zumindest einen sehr ähnlichen IC.
Der ist immer anders gelabelt und bei mir sogar komplett unbeschriftet.
Es handelt sich glaube ich um diesen hier als 20-Pin SSOP Variante.
Das einzige was daran unstimmig ist, ist die Tatsache, dass Pin18 "RA7/OSC1/CLKI/T1OSI(1)/FLTA(2)" der PWM Ausgang 5 ist (und PIN11 "RB4/PWM2" mit dem Binding Pin vom Empäfnger verbunden ist) ... ansonsten kommt das hin

Somit hätten wir jetzt zumindest mal alle Bauteile identifiziert und dessen Datenblätter

Im Anhang hab ich auch nochmal ein Bild mit der Pinbelegung vom Board.
Wo geht die gelbe leitung zwischen dem A7105 und dem Demultiplexer hin?
Ich hab schon alles durchgeklingelt

[pylon]

Funke aus:
10
15
0, 15, VARIABEL, VARIABEL
12

"10" bzw. "1010b" ist ein sog. Strobe-Command welches den Chip in den Standby-Mode versetzt.

"15" bzw. "1111b" ist ebenfalls ein Strobe-Command, das den FIFO-Zeiger zurücksetzt.

Das kurze Hochziehen von SCS ist notwendig, da der Controller sonst das volle Byte für den Strobe-Command senden müsste obwohl die unteren 4 Bit irrelevant sind.

"0, 15" bzw. "00001111" ist die Anforderung zum Auslesen von Register Nr. 15 (PLL 1).

Somit siehst Du hier also durchaus normalen Bus-Verkehr für diesen Chip.
Leider ist somit aber auch klar, dass Du hier nichts verändern kannst, solange der andere Controller den Bus für sich beansprucht. Die bleibt also nichts anderes übrig, als den Controller vom Bus zu entfernen oder passiv mitzuhören, was allerdings wahrscheinlich nicht den von Dir gewünschten Effekt hätte.

[Leon333]

Alter wo nimmst du denn diese ganzen Informationen her?
zu dem "10" bzw. 1010b und dem "15" bzw. 111b kann ich nirgends was finden.

Nicht, dass ich dir das nicht glaube, bloß weiß ich nicht, wie ich jemals auf diese Info hätte kommen können

Von welchem Chip redest du denn? Wird damit der A7105 oder der PIC18F1230 in den Standby-Mode versetzt und der FIFO-Zeiger zurückgesetzt?

Ich denke, damit versetzt man den A7105 in den Standby-Mode etc. aber wozu? damit der nicht mehr das Funksignal auswertet, sondern darauf wartet, was für Informationen der PIC18F1230 von ihm haben will?
Dann müsste das "12" bzw "1100b" ja so etwas wie "weitermachen!" sein

Die VARIABEL Werte sahen z.B. folgendermaßen aus:
10
15
0, 15, 3, 2
12

10
15
0, 15, 6, 4
12

Demnach müsste "3, 2" ja "00110010b" sein (DEC 50, 32h) und wenn ich das richtig sehe, ist es das Register für "Filter test"
und "6, 4" ist "01100100b" (DEC 100) und dazu gibt es nicht mal ein Register...
Was wird denn da immer mal anders abgefragt?

Ich verstehe auch nicht, warum das Protokoll mal in 4bit spezielle Kommandos sendet (Standby-Mode etc) und sonst in 8bit Kommuniziert.
Oder ist das hier alles auf 4bit basierend?
Mit dem Arduino müsste ich dann bei den ganzen 4bit Kommandos die Pulse eigens setzen, weil standardmäßg ja in kompletten bytes gesendet/geschrieben wird oder?

Das mit dem Auslöten des PIC18F1230 werde ich morgen machen.
Da werde ich einer weiteren Person nen Lötkolben in die Hand drücken, damit wir zusammen schnell (und hoffentlich unbeschadet) den PIC18F1230 mit seinen 20Pins auslöten können.
Weil ich weiß nicht, wie ich das alleine sonst schaffen sollte.

Eben ist allerdings auch mein Oszilloskop angekommen.
Damit hab ich mal den "RSSI"-Ausgang gemessen.
Zuerst dachte ich, dass das immer identisch sei, ist es aber nicht.
Ich hab mal Bilder davon gemacht und der im ersten Bild rote Abschnitt ändert sich.
Wenn das Signal super ist, dann ist die Spannung in diesem Abschnitt etwa bei 16mV,
bei relativ schlechtem Empfang bei 200mV und bei ganz schlechtem Empfang bei fast 300mV.

Dazu muss ich aber sagen, dass ich mich mit dem Oszilloskop noch nicht auskenne und diese Werte daher mit vorsicht zu genießen sind.
Dennoch ist die Tendenz klar - wenn der Empfang schlecht ist, dann steigt die Spannung in dem Abschnitt.

THEORETISCH könnte ich mit dem Arduino am RSSI analog lesen und den Wert bei fallender Flanke von GIO1 als groben schätzwert nehmen.
Bloß ist das RSSI soweit ich weiß sowieso schon recht grob unterteilt und das 5V Arduino gibt mir eine ~5mV Auflösung bei einer Standardabweichung von +-5mV (oder so ähnlich?)

Das wäre jedenfalls besser als gar nichts und ich hätte "ohne Hardware modifikationen" (haha) zumindest ein gewisses RSSI Signal.
Wenn das Signal aber abreißt/schwach wird, dann zappelt alles im Oszilloskop, weil dann die Signale mit einem anderen Intervall rein kommen (sieht man ab dem "mittleren Empfang" Screenshot anhand des veränderten blauen Verlaufs).

Was meinst du zu dieser Alternative?

Dennoch will ich das mit dem direktem Auslesen und deiner Hilfe versuchen.
Ich melde mich dann wieder, wenn der PIC18F1230 draußen ist.

[pylon]

Alter wo nimmst du denn diese ganzen Informationen her?
zu dem "10" bzw. 1010b und dem "15" bzw. 111b kann ich nirgends was finden.

Das steht im Datenblatt, Kapitel 10.4. "10" ist die Dezimalschreibweise von binär "1010", also keine Hexerei.

Von welchem Chip redest du denn? Wird damit der A7105 oder der PIC18F1230 in den Standby-Mode versetzt und der FIFO-Zeiger zurückgesetzt?

Der A7105, beim PIC gehe ich immer noch davon aus, dass Du den entfernen wirst :-).

Demnach müsste "3, 2" ja "00110010b" sein (DEC 50, 32h) und wenn ich das richtig sehe, ist es das Register für "Filter test"

Nein, 0x32 scheint der Inhalt von Register 15 zu sein, so jedenfalls meine Interpretation.

Ich verstehe auch nicht, warum das Protokoll mal in 4bit spezielle Kommandos sendet (Standby-Mode etc) und sonst in 8bit Kommuniziert.
Oder ist das hier alles auf 4bit basierend?
Mit dem Arduino müsste ich dann bei den ganzen 4bit Kommandos die Pulse eigens setzen, weil standardmäßg ja in kompletten bytes gesendet/geschrieben wird oder?

Die 4-Bit-Sachen sind Strobe-Commands, der Rest ist 8-bit-basiert. Mit dem Arduino kannst Du auch die Strobe-Commands als 8-Bit-Werte schicken, die restlichen 4 Bit werden dann einfach ignoriert.

Da werde ich einer weiteren Person nen Lötkolben in die Hand drücken, damit wir zusammen schnell (und hoffentlich unbeschadet) den PIC18F1230 mit seinen 20Pins auslöten können.
Weil ich weiß nicht, wie ich das alleine sonst schaffen sollte.

Heissluft-Auslötstation, damit mache ich solche Übungen.

Eben ist allerdings auch mein Oszilloskop angekommen.
Damit hab ich mal den "RSSI"-Ausgang gemessen.
Zuerst dachte ich, dass das immer identisch sei, ist es aber nicht.
Ich hab mal Bilder davon gemacht und der im ersten Bild rote Abschnitt ändert sich.
Wenn das Signal super ist, dann ist die Spannung in diesem Abschnitt etwa bei 16mV,
bei relativ schlechtem Empfang bei 200mV und bei ganz schlechtem Empfang bei fast 300mV.

Entschuldige, von der Funktechnik verstehe ich gar nichts. Ich dachte, da seist Du der Spezialist, sonst würdest Du Dich wohl nicht an solche Chips wagen.

Bloß ist das RSSI soweit ich weiß sowieso schon recht grob unterteilt und das 5V Arduino gibt mir eine ~5mV Auflösung bei einer Standardabweichung von +-5mV (oder so ähnlich?)

Die Auflösung von 5mV kommt ungefähr hin, aber Standardabweichung wirst Du deutlich mehr haben. Das hängt hingegen auch davon ab, wie Du den Arduino mit Strom versorgst und welche anderen Verbraucher noch dran hängen.

Wenn das Signal aber abreißt/schwach wird, dann zappelt alles im Oszilloskop, weil dann die Signale mit einem anderen Intervall rein kommen (sieht man ab dem "mittleren Empfang" Screenshot anhand des veränderten blauen Verlaufs).

Ich nehme mal an, die gelbe Kurve ist RSSI. Was ist dann das blaue Signal?

[Leon333]

Oh sorry, da ist ein Teil verlorgen gegangen...
Das gelbe Signal ist der RSSI Ausgang des A7105 - korrekt!
Das blaue ist der GIO1.
Da dieses Signal immer nur einmal seinen Status ändert, dachte ich, es wäre als Referenz am besten geeignet.
Und in der Tat könnte ich das auch mit der oben beschriebenen Messungenauigkeit nutzen (aber wozu schlecht machen, wenn einem ein Profi wie du dabei hilft es ordentlich zu machen?

Zum RSSI: Da gibt es keinen Standard wie das Signal in einem Empfänger vorliegt... da kochte jeder Hersteller... eigentlich sogar jedes Modell sein eigenes Süppchen.
Dennoch war ich darüber verwundert wie ungünstig (zum hacken) das Signal vorliegt.

Meine lebende "helping hand" hat es leider noch nicht zu mir geschafft und daher ist der PIC NOCH drinne.
Du kannst mir aber gerne deine Heißluft Auslötstation zusenden, wenn es dir zu lange dauert (hach was wäre so ein Werkzeug praktisch)

Aber ich habe noch eine weitere Idee...
diese Woche sollte noch ein 3.3V Arduino pro Mini kommen.
Dann könnte ich mich direkt an den A7105 hängen ohne Level-shifter... brauche eben nur etwa 2 Stunden um den anderen da raus zu löten :D:D

[Tommy56]

Leon333:
Du kannst mir aber gerne deine Heißluft Auslötstation zusenden, wenn es dir zu lange dauert (hach was wäre so ein Werkzeug praktisch)

Ich habe mir dieses Teil zugelegt und finde es ganz praktisch. Es ist ja auch nicht teuer.

Gruß Tommy

[Leon333]

Das ist tatsächlich ne Überlegung wert.
Direkt aus China ab 30€ und sogar mit Ersatzheizelement... kommt auf die Whishlist

Ich hab jetzt mal den PIC alleine ausgelötet... war leichter als erwartet.
Hab einfach beide Beinleisten vorsichtig erstmal mit lot bentzt und dann mit zwei Lötkolben gleichzeitig die Seiten erhitzt und zack... war er ab.

Nun warte ich noch auf mein 3.3V Arduino Pro Mini.. das sollte sehr bald kommen.
In der Zwischenzeit löte ich schonmal das 5V Pro Mini aus und schließe dann mal den Level Converter an um schonmal anfangen zu können.

Wenn ich jetzt vom Arduino aus was anfragen möchte, dann muss ich zuerst den A7105 in den Standby-Mode versetzen und dann den FIFO-Zeiger zurücksetzen?
Serial.print() oder SortSerial.print() sollte da nicht funktionieren oder?
Die schicken ja immer noch zusätzlich ein /r mit...
Ginge Serial.write() oder muss ich die bits einzelnd per "HIGH" und "LOW" schreiben?
Standby sollte ja als Byte (z.B.) eine "80" sein und den FIFO-Zeiger kann ich (z.B.) mit 240 zurück setzen, wenn Bytes senden klappt...
Man sieht ich bin noch "lost"

[pylon]

Wenn ich jetzt vom Arduino aus was anfragen möchte, dann muss ich zuerst den A7105 in den Standby-Mode versetzen und dann den FIFO-Zeiger zurücksetzen?

Ob das so gemacht werden muss, weiss ich nicht, aber der PIC scheint so vorgegangen zu sein. Wie gesagt, von dem, was der Chip macht, habe ich so ziemlich null Ahnung, ich habe nur schon häufiger mit SPI gearbeitet und habe gelernt, Datenblätter zu lesen.

Serial.print() oder SortSerial.print() sollte da nicht funktionieren oder?

Ich kenne das SortSerial-Objekt nicht, woher stammt das?

Die schicken ja immer noch zusätzlich ein /r mit...

Nein, die println()-Methode schickt \r und \n (also ASCII 13 und 10) mit, die print()-Methode verschickt nur den String.

Ginge Serial.write() oder muss ich die bits einzelnd per "HIGH" und "LOW" schreiben?

Wenn Du auf den SPI-Bus schreiben willst, dann ist das Serial-Objekt der falsche Weg. Das geschieht über das SPI-Objekt und dieses kennt weder print() noch write() Methoden. Dort wird mit transfer() gearbeitet, welches gleichzeitig sendet und empfängt (entsprechend der SPI-Besonderheit).

Standby sollte ja als Byte (z.B.) eine "80" sein und den FIFO-Zeiger kann ich (z.B.) mit 240 zurück setzen, wenn Bytes senden klappt...

Ich bekomme "160" für den Standby Strobe Command, aber bei 240 stimme ich zu. Das Senden von Bytes müsste gehen, da es im Datenblatt explizit (mit Beispielen) erwähnt wird.

Man sieht ich bin noch "lost"

So lost nun auch wieder nicht mehr :-).

[Leon333]

Das "SortSerial-Objekt" sollte ein Software-Serial sein.. ist im Ergebnis aber wie das HardwareSerial.

Bei den "80" hatte ich im Binärrechner hinten eine "0" vergessen... so wurde aus den eigentlichen 160 eine fälschliche 80.

Ich habe mein 3.3V Pro Mini noch nicht da, zum Spaß hab ich aber mal mit dem Oszilloskop gemessen ob der A7105 irgendwo irgendwas ausgibt.
Auf GIO1, SCS, SCK, RSSI und SDIO ist alles still.

Wenn ich jetzt irgendwie mit dem A7105 kommunizieren will, wie mache ich das?
Die SPI library nutzt ja eigentlich ein 4-wire SPI protokoll und ich würde gerne auf 3-wire bleiben einfach, weil ich befürchte nicht mehr zurück zu kommen, wenn ich den A7105 jetzt auf 4-wire "umprogrammiere" - und ausßerdem ist das Löten deutlich einfacher an den SCS, SDIO und SCK pads als an dem beinchen des A7105 (für Nachmacher).

Erstes Problem:
Ich muss der SPI library irgendwie sagen, dass alles über einen Pin rein und raus geht.

Nächstes Problem:
Ich weiß nicht was der erste Teil meines Mitschnittes macht, weil Register "64" / "40h" nicht existiert.

Woher weiß der A7105 eigentlich ob gerade ein strobe command oder eine normale Registerabfrage kommt?

Das was ich jetzt mal so grob zusammen geschrieben habe ist das hier, aber das fehlt es noch an einigem, damit es was werden kann:

#include "SPI.h"

// define the SPI pins
#define SDIO 12
#define SCS 10

// strobe commands
byte setStandby = 160;
byte setFIFOreadPointer = 240;
byte setRXmode = 192;

// adresses
byte RSSIadress = 29;
byte PLL1adress = 15;

// commands
byte PLL1reset = 0;

// storage for the channel values
byte receivedValues[22];

// storage for the RSSI signal
byte rssi = 0;

// reveived SPI value
byte result = 0;

void strobeSPI(byte value)
{
  digitalWrite(SCS, LOW);
  SPI.transfer(value);
  digitalWrite(SCS, HIGH);
}

//PLL1 register adress is 15, reset command is 0
void PLL1reset()
{
  digitalWrite(SCS, LOW);
  SPI.transfer(PLL1adress);
  SPI.transfer(PLL1reset);
  digitalWrite(SCS, HIGH);
}

void readWriteSPI(byte value)
{
  digitalWrite(SCS, LOW);
  SPI.transfer(value);
  result = SPI.transfer(0);
  digitalWrite(SCS, HIGH);
}

void setup()
{
  pinMode(SCS, OUTPUT);
  digitalWrite(SCS, HIGH);
  SPI.begin(); 
  SPI.setBitOrder(MSBFIRST);
}

void loop()
{

  // den ersten Teil mit "64, 24"
  // und 69, 85, 223, 184, 1, 0, 223, 3, 224, 3, 223, 3, 224, 3, 223, 3, 224, 3, 223, 3, 223, 3, 
  // hab ich noch nicht
  //readWriteSPI();
  
  strobeSPI(setStandby);
  strobeSPI(setFIFOreadPointer);
  PLL1reset();
  strobeSPI(setRXmode);

}

Ich Depp hätte außerdem mal den Anfang beim starten des Emfängers mitschneiden sollen - und am besten auch einen mitschnitt von der Kopplung des Empfängers mit der Fernbedienung....
Nochmal einlöten ist jetzt auch irgendwie doof

[Serenifly]

https://www.totalphase.com/support/articles/200350046-Interfacing-with-3-wire-SPI/#s1.1.3.1

Ansonsten wird das oft in Software implementiert

[pylon]

Erstes Problem:
Ich muss der SPI library irgendwie sagen, dass alles über einen Pin rein und raus geht.

Das geht leider nicht, wenn Du die 3-Draht-Verbindung haben willst, dann muss das in Software emuliert werden. Ich würde jedoch zu einem 4-Draht-Verkehr raten, denn bei einem Fehler bei der 3-Draht-Kommunikation könnte der Arduino und der A7105 Schaden nehmen (Kurzschluss). Das ist schnell passiert, ein falsches Kommando und der A7105 sendet während der Arduino auch noch am Senden ist. Wenn der A7105 ein 0, der Arduino aber ein 1 sendet, ist der Kurzschluss schon da. Du könntest Widerstände einbauen, die den Strom tief halten, aber das macht den Bus auch sehr schnell ätzend langsam.

Ich weiß nicht was der erste Teil meines Mitschnittes macht, weil Register "64" / "40h" nicht existiert.

Woher kommt das 0x40? In den geposteten Daten kann ich das nicht finden.

Woher weiß der A7105 eigentlich ob gerade ein strobe command oder eine normale Registerabfrage kommt?

Über das CS-Signal. Wenn das bereits nach 4 Bit hochgezogen wird, dann ist quasi ein Byte durch und es müsste sich um ein Strobe Command gehandelt haben. Zudem ist bei Strobe-Commands immer das erste Bit gesetzt. Dies ist bei normalem 8-Bit-Betrieb das Unterscheidungsmerkmal.

Ich Depp hätte außerdem mal den Anfang beim starten des Emfängers mitschneiden sollen - und am besten auch einen mitschnitt von der Kopplung des Empfängers mit der Fernbedienung....

Ich habe noch nicht ganz verstanden, wie die Fernbedienung hier einbezogen wird. Wo war die angschlossen? Am PIC? Woher ist denn die Platine? War die in einem kommerziellen Gerät verbaut?

Grundsätzlich haben wir die Dokumentation, damit sollten wir die wichtigen Dinge eigentlich auch wieder hin bekommen.

[Leon333]

Zum 3-Draht-SPI: ist von der Argenda gestrichen und sobald das 3.3V Arduino (endlich mal) ankommt, wird mit 4-Draht kommuniziert.

Das 0x40 kommt vom 8byte Mitschnitt per LA, siehe dazu das Bild 04_ Funke an SPI.PNG im Beitrag #6.

Das mit den Strobe-Commands hab ich nun endlich verstanden - danke dir pylon.

Auch an dich danke, Serenifly, aber aufgrund mangelnder Erfahrung mit SPI und der "Gefahrenhinweis" von pylon, werde ich das mal (oder zumindest erstmal) nicht mit dem Widerstand und 3-pin SPI versuchen.

Zu dem Empfänger:
Es ist ein 2.4GHz Funk-Empfänger zur Modell-Fernsteuerung (von Flugzeugen, Booten, Autos, Panzer, etc.).
Der Empfänger wird von zwei Herstellern, namens Turnigy und FlySky kommerziell verkauft, ist im Inneren aber identlisch.
Das Modell gibt es zum Beispiel hier oder hier.

Es ist jetzt nicht das Nonplusultra-Gerät, aber eine Reichweite von etwa 1km reicht mir erstmal dicke und mit meinen Moduifikationen hat es vom Leistungsumfang mehr zu bieten als die meisten Fernsteuerung/Empfänger-Kombinationen, die über das 6fache kosten.

Am Anfang muss man die Fernsteuerung mit dem Empfänger einmal koppeln.
Das macht man, indem man einen bestimmten Pin am Empfänger HIGH setzt und an der Fernbedienung einen Knopf drückt.
Was genau da passiert weiß ich nicht. Sicher ist aber, dass der hellblau markierte Kontakt oben rechts 5V bekommt und somit wahrscheinlich irgendwelche ID-Daten in den EEPROM geschrieben werden.
Sobald die beiden gekoppelt sind und man beide Geräte an hat, leuchtet dann die Diode (links vom SDA des EEPROMs auf dem Bild).

Dadurch, dass ich den PIC entfernt habe, sehe ich nun auch wo die Gelbe Verbindung hin geht.
Sie verbindet GIO1 des A7105 mit dem Pin4 des PIC, der mit "MCLR/VPP/RA5/FLTA(2)" Bezeichnet ist.

Die Beschreibung bei TABLE 1-2: PIC18F1230/1330 PINOUT I/O DESCRIPTIONS dazu lautet:

Master Clear (input), programming voltage (input)
or Fault detect input.
Master Clear (Reset) input. This pin is an
active-low Reset to the device.
Programming voltage input.
Digital input.
Fault detect input for PWM.

Das ist interessant, weil der GIO1 ja kurz vor dem Senden dieser ganzen Bytes (oder Strobe-Commands) auf LOW gesetzt wurde und die komplette Zeit in dem ich Daten mitgeschnitten hatte, das Level vom GIO1 auch auf LOW blieb.
Heißt das also, dass der A7105 hier zuerst den PIC resetet, der dann die Daten anfordert (oder auch ohne gesendet bekommt) und anschließend den A7105 wieder per Strobe-Commands zurück setzt?

Da muss aber vorher noch irgendetwas passieren, weil wenn ich jetzt auf GIO1 mit dem Oszilloskop lausche, dann bekomme ich nichts zu sehen (außer etwas rauschen).

Also Status aktuell: An keinem der für mich greifbaren Pins des A7105 passiert irgendetwas messbares.
Das wird sich hoffentlich ändern, wenn ich mit einem Arduino mit dem A7105 kommuniziere und ich hoffe auch sehr, dass der Empfänger noch funktioniert und der PIC nicht irgendwelche Daten aus dem EEPROM läd und den A7105 dadurch erst mit der Fernbedienung genutzt werden kann.