Hallo zusammen,
ich habe einen Tiny85 mit der Library von mchr3k/arduino-libs-manchester
geflasht, um Daten an einen Raspberry Pi Model 1B zu senden. Die GPIOs
des Raspberry Pi werden über die Schnittstelle pigpio angesprochen.
Daher hatte ich gehofft, dass die Manchester-Implementierung unter
pigpio examples – Kapitel „pigpiod_if2 code“
die Daten lesen kann. Leider war dies nicht der Fall, weshalb ich in
Ermangelung einer passenden Library versucht habe, die Arduino-Lib auf
der Empfängerseite selbst zu programmieren.
Soweit ich es verstanden habe, sendet die Library in ihrem Beispiel ein
8-Bit-Paket. Der Tiny85 läuft auf 8 MHz, und ich habe die Baudrate auf
MAN_1200 eingestellt. Vor dem Senden der Nutzdaten wird ein Sync-Muster
[0,0,0,1] geschickt, das in Manchester-Codierung als
[(1,0),(1,0),(1,0),(0,1)] dargestellt wird. Wenn ich es richtig
beobachtet habe, beträgt der Takt, den der Tiny sendet, stets 750 µs,
auf den die Manchester-Codierung aufgesetzt ist.
Mein Problem ist nun, dass ich zwar die Flankenerkennung am GPIO bekomme
– und das sind sehr wahrscheinlich meine Daten – ich diese jedoch nicht
korrekt zusammenbauen kann. Wenn ich jedoch einen anderen Raspberry Pi
mit einem Sender ausstatte und das Pigpio-Beispiel verwende, werden die
Daten problemlos übertragen.
Anbei die Flanken mit den Zeiten
1
2
Tick: 4193214804, Level: 0, Δt: 894 µs
3
Tick: 4193217125, Level: 0, Δt: 1655 µs
4
Tick: 4193218575, Level: 1, Δt: 1450 µs
5
Tick: 4193219450, Level: 0, Δt: 875 µs
6
Tick: 4193221765, Level: 0, Δt: 1645 µs
7
Tick: 4193223350, Level: 0, Δt: 890 µs
8
Tick: 4193224789, Level: 1, Δt: 1439 µs
9
Tick: 4193225645, Level: 0, Δt: 856 µs
10
Tick: 4193227965, Level: 0, Δt: 1630 µs
11
Tick: 4193228670, Level: 1, Δt: 705 µs
12
Tick: 4193229530, Level: 0, Δt: 860 µs
13
Tick: 4193231075, Level: 0, Δt: 855 µs
14
Tick: 4193232554, Level: 1, Δt: 1479 µs
15
Tick: 4193233390, Level: 0, Δt: 836 µs
16
Tick: 4193234100, Level: 1, Δt: 710 µs
17
Tick: 4193234960, Level: 0, Δt: 860 µs
18
Tick: 4193236505, Level: 0, Δt: 854 µs
19
Tick: 4193237205, Level: 1, Δt: 700 µs
20
Tick: 4193238054, Level: 0, Δt: 849 µs
21
Tick: 4193238760, Level: 1, Δt: 706 µs
22
Tick: 4193239600, Level: 0, Δt: 840 µs
23
Tick: 4193240310, Level: 1, Δt: 710 µs
24
Tick: 4193241925, Level: 0, Δt: 1615 µs
25
Tick: 4193242645, Level: 1, Δt: 720 µs
26
Tick: 4193243475, Level: 0, Δt: 830 µs
27
Tick: 4193244970, Level: 1, Δt: 1495 µs
28
Tick: 4193245805, Level: 0, Δt: 835 µs
29
Tick: 4193246520, Level: 1, Δt: 715 µs
30
Tick: 4193247350, Level: 0, Δt: 830 µs
31
Tick: 4193248075, Level: 1, Δt: 725 µs
32
Tick: 4193248905, Level: 0, Δt: 830 µs
33
Tick: 4193249625, Level: 1, Δt: 720 µs
34
Tick: 4193250465, Level: 0, Δt: 840 µs
35
Tick: 4193251180, Level: 1, Δt: 715 µs
36
Tick: 4193252790, Level: 0, Δt: 1610 µs
37
Tick: 4193254290, Level: 1, Δt: 1500 µs
38
Tick: 4193255105, Level: 0, Δt: 815 µs
39
Tick: 4193255840, Level: 1, Δt: 735 µs
40
Tick: 4193256660, Level: 0, Δt: 820 µs
41
Tick: 4193257395, Level: 1, Δt: 735 µs
42
Tick: 4193258210, Level: 0, Δt: 815 µs
43
Tick: 4193258945, Level: 1, Δt: 735 µs
44
Tick: 4193259770, Level: 0, Δt: 825 µs
45
Tick: 4193260500, Level: 1, Δt: 730 µs
46
Tick: 4193261320, Level: 0, Δt: 820 µs
47
Tick: 4193262051, Level: 1, Δt: 731 µs
48
Tick: 4193262870, Level: 0, Δt: 819 µs
49
Tick: 4193263605, Level: 1, Δt: 735 µs
50
Tick: 4193264425, Level: 0, Δt: 820 µs
51
Tick: 4193265155, Level: 1, Δt: 730 µs
52
Tick: 4193265980, Level: 0, Δt: 825 µs
53
Tick: 4193266710, Level: 1, Δt: 730 µs
54
Tick: 4193267530, Level: 0, Δt: 820 µs
55
Tick: 4193268260, Level: 1, Δt: 730 µs
56
Tick: 4193269075, Level: 0, Δt: 815 µs
57
Tick: 4193269810, Level: 1, Δt: 735 µs
58
Tick: 4193270625, Level: 0, Δt: 815 µs
59
Tick: 4193271370, Level: 1, Δt: 745 µs
60
Tick: 4193272185, Level: 0, Δt: 815 µs
61
Tick: 4193272920, Level: 1, Δt: 735 µs
62
Tick: 4193273731, Level: 0, Δt: 811 µs
63
Tick: 4193274470, Level: 1, Δt: 739 µs
64
Tick: 4193275285, Level: 0, Δt: 815 µs
65
Tick: 4193276020, Level: 1, Δt: 735 µs
66
Tick: 4193277610, Level: 0, Δt: 1590 µs
67
Tick: 4193278355, Level: 1, Δt: 745 µs
68
Tick: 4193279170, Level: 0, Δt: 815 µs
69
Tick: 4193280685, Level: 1, Δt: 1515 µs
70
Tick: 4193281495, Level: 0, Δt: 810 µs
71
Tick: 4193282240, Level: 1, Δt: 745 µs
72
Tick: 4193283040, Level: 0, Δt: 800 µs
73
Tick: 4193283790, Level: 1, Δt: 750 µs
74
Tick: 4193284595, Level: 0, Δt: 805 µs
75
Tick: 4193285350, Level: 1, Δt: 755 µs
76
Tick: 4193286145, Level: 0, Δt: 795 µs
77
Tick: 4193286895, Level: 1, Δt: 750 µs
78
Tick: 4193287695, Level: 0, Δt: 800 µs
79
Tick: 4193288452, Level: 1, Δt: 757 µs
80
Tick: 4193289255, Level: 0, Δt: 803 µs
81
Tick: 4193290000, Level: 1, Δt: 745 µs
82
Tick: 4193291575, Level: 0, Δt: 1575 µs
83
Tick: 4193293100, Level: 1, Δt: 1525 µs
84
Tick: 4193293910, Level: 0, Δt: 810 µs
85
Tick: 4193294655, Level: 1, Δt: 745 µs
86
Tick: 4193295460, Level: 0, Δt: 805 µs
87
Tick: 4193296215, Level: 1, Δt: 755 µs
88
Tick: 4193297005, Level: 0, Δt: 790 µs
89
Tick: 4193297765, Level: 1, Δt: 760 µs
90
Tick: 4193298555, Level: 0, Δt: 790 µs
91
Tick: 4193299315, Level: 1, Δt: 760 µs
92
Tick: 4193300110, Level: 0, Δt: 795 µs
93
Tick: 4193300865, Level: 1, Δt: 755 µs
94
Tick: 4193302435, Level: 0, Δt: 1570 µs
95
Tick: 4193303200, Level: 1, Δt: 765 µs
96
Tick: 4193303990, Level: 0, Δt: 790 µs
97
Tick: 4193304745, Level: 1, Δt: 755 µs
98
Tick: 4193305535, Level: 0, Δt: 790 µs
1
import pigpio
2
3
pi = pigpio.pi()
4
PIN = 17
5
6
last_tick = None # Zeitpunkt der letzten Flanke
7
flanken_liste = [] # hier speichern wir die Flanken >700 µs
8
9
def callback_func(gpio, level, tick):
10
global last_tick, flanken_liste
11
12
if level in (0, 1): # nur echte Flanken
13
if last_tick is not None:
14
delta = pigpio.tickDiff(last_tick, tick) # Zeitdifferenz in µs
15
16
if delta >= 700: # nur Flanken über 700 µs speichern
Falsches Forum.
Forum: Projekte & Code
Hier könnt ihr Projekte, Schaltungen oder Codeschnipsel vorstellen.
Projekte bitte nur mit Code oder Schaltplan posten (falls ihr nur Fotos
vorstellen möchtet, bitte in "Zeigt her eure Kunstwerke"). Bitte hier
keine Fragen posten.
Ich verschiebe das mal...
Manchester kann man schon mit den nur 35 Befehlen der Base-PICs
sehr einfach dekodieren. Oder mit einem Z80 mit einem 1 MHz Takt.
Versuchs noch einmal etwas hardwarenäher.
Dabei lernst du dann auch, wie man auf die GPIOs z.B. in C zugreifen
kann. Für die reine Dekodierung würde ich aber immer noch ARM-Assembler
vorziehen. Beachte dabei auch, dass die graue Eminenz in einem Pi,
der Videocore, den ARM zu ihrer eigenen Disposition arbeiten lässt.
Das äussert sich dann in gewissen Aufmerksamkeitsdefiziten wenn dein
Code läuft. Ob das dann noch für dich brauchbar ist, musst du selbst
herausfinden. Bei mir ist an der Stelle der Pi vom Tisch in die Ecke
geflogen...
Lars L. schrieb:> ich habe die Baudrate auf MAN_1200 eingestellt. {...}> Wenn ich es richtig> beobachtet habe, beträgt der Takt, den der Tiny sendet, stets 750 µs,
Eher 833 µs (1/1200 Hz).
Cartman E. schrieb:> Manchester kann man schon mit den nur 35 Befehlen der Base-PICs> sehr einfach dekodieren. Oder mit einem Z80 mit einem 1 MHz Takt.>> Versuchs noch einmal etwas hardwarenäher.> Dabei lernst du dann auch, wie man auf die GPIOs z.B. in C zugreifen> kann. Für die reine Dekodierung würde ich aber immer noch ARM-Assembler> vorziehen. Beachte dabei auch, dass die graue Eminenz in einem Pi,> der Videocore, den ARM zu ihrer eigenen Disposition arbeiten lässt.> Das äussert sich dann in gewissen Aufmerksamkeitsdefiziten wenn dein> Code läuft. Ob das dann noch für dich brauchbar ist, musst du selbst> herausfinden. Bei mir ist an der Stelle der Pi vom Tisch in die Ecke> geflogen...
Hallo,
glaube es war mein Fehler, wollte das ganze eigentlich mit für ein
Projekt verwenden und nicht noch ein extra IC dazwischen hängen. Die
Interrupt Dekodierung sieht Interessant aus, wenn alles fertig ist zu
Übungszwecken versuche ich es einmal.
Dieses ständige ändern der Zeiten der Daten hat mich auch ein wenig
stutzig gemacht. Ich habe nun kein Gefühl dafür ob das diese Zeiten noch
tolerierbar sind oder dies schon der Fehler ist. Wie gesagt von Raspi zu
Raspi über C++ funktioniert es wunderbar und vermutlich funktioniert es
auch blind von IC zu IC.
Lars L. schrieb:> Dieses ständige ändern der Zeiten der Daten hat mich auch ein wenig> stutzig gemacht.
Du brauchst eine bimodale Verteilung, bei der die Häufigkeit in der
Mitte zwischen den beiden Maxima wirklich auf 0 geht. Solange das
erfüllt ist, ist alles gut.
Rainer W. schrieb:> Lars L. schrieb:>> Dieses ständige ändern der Zeiten der Daten hat mich auch ein wenig>> stutzig gemacht.>> Du brauchst eine bimodale Verteilung, bei der die Häufigkeit in der> Mitte zwischen den beiden Maxima wirklich auf 0 geht. Solange das> erfüllt ist, ist alles gut.
Hallo Rainer,
ich hatte zwar Jahren Statistik gehabt, aber der Begriff hat mir nichts
gesagt :D
Also ja, zwischen den Maxima geht es auf null, der Mittelwert liegt bei
783µs und die Standardabweichung liegt bei 50µs.
Mal so eine sidequest Frage, was ist der Hintergrund dieses Phänomens?
Meine Erwartung wären eher das bei der Abbildung der Häufigkeiten der
Zeiten eine Art Glockenkurve entsteht und nicht umgekehrt. Ich habe die
höheren Werte die über 1000µs liegen rausgenommen und nur in dem Bereich
zwischen 700 und 900 genommen. Oder habe ich da etwas komplett Falsch
verstanden :D
Lars L. schrieb:> Meine Erwartung wären eher das bei der Abbildung der Häufigkeiten der> Zeiten eine Art Glockenkurve entsteht und nicht umgekehrt.
Was meinst du mit "umgekehrt"?
> Also ja, zwischen den Maxima geht es auf null, der Mittelwert liegt bei> 783µs und die Standardabweichung liegt bei 50µs.
Die 783µs ist der Mittelwert des einen Maximums und entspricht dem
Abstand zwischen zwei Clockflanken. Der Mittelwert des zweiten Maximums
muss etwa bei dem doppelten Wert liegen und der Symboldauer im
Datenstrom entsprechen. Dein Mittelwert entspricht einer Datenrate von
640 Bd.
Die langen Zeiten zwischen den Flanken entstehen, wenn im Datenstrom
unterschiedliche Bits aufeinander folgen, die kurzen, wenn gleiche Bits
aufeinander folgen.
https://de.wikipedia.org/wiki/Manchester-Code
Bei einer Datenrate von 1200 Bd müssten im Manchestercode Pulse/Pausen
mit 417 µs und 833 µs, entsprechen der halben und der ganzen Symbolzeit,
auftreten.
Rainer W. schrieb:> Lars L. schrieb:>> Meine Erwartung wären eher das bei der Abbildung der Häufigkeiten der>> Zeiten eine Art Glockenkurve entsteht und nicht umgekehrt.>> Was meinst du mit "umgekehrt"?>>> Also ja, zwischen den Maxima geht es auf null, der Mittelwert liegt bei>> 783µs und die Standardabweichung liegt bei 50µs.>> Die 783µs ist der Mittelwert des einen Maximums und entspricht dem> Abstand zwischen zwei Clockflanken. Der Mittelwert des zweiten Maximums> muss etwa bei dem doppelten Wert liegen und der Symboldauer im> Datenstrom entsprechen. Dein Mittelwert entspricht einer Datenrate von> 640 Bd.> Die langen Zeiten zwischen den Flanken entstehen, wenn im Datenstrom> unterschiedliche Bits aufeinander folgen, die kurzen, wenn gleiche Bits> aufeinander folgen.> https://de.wikipedia.org/wiki/Manchester-Code>> Bei einer Datenrate von 1200 Bd müssten im Manchestercode Pulse/Pausen> mit 417 µs und 833 µs, entsprechen der halben und der ganzen Symbolzeit,> auftreten.
Okay ich glaube ein wenig haben wir uns da missverstanden? :D
Ich habe mal ein paar Auswertungen getätigt, hier die Graphen. Das erste
Histogramm zeigt in den Grenzen zwischen 700 und 900 die Häufigkeit der
Daten. Dabei habe ich die langen Flanken für ein Bitübergang
herausgefiltert.
der zweite Graph zeigt die Verteilung von einen Raspi zum anderen Raspi
über 433Mhz Sender und Empfänger von der cpp Implementierung. Diese habe
ich leicht angepasst und die Werte herausschreiben lassen. Gott sei dank
hat der Entwickler den printf Befehl im Code gelassen :D
der letzte Graph nochmal alle Daten aber vom tiny zum Raspi dabei ist
das erstes Max_mean: 1552.8666666666666 und zweites Max_mean:
783.2926829268292
Okay vielleicht liegt da im TinyQuellcode ein Problem oder der IC läuft
nicht ganz mit 8Mhz. Ich hatte halt die Standard Einstellungen
hergenommen. Aber rein Theoretisch selbst wenn es langsamer läuft,
zumindest sind die Flankenänderungen zu erkennen nur die Streuung um den
Mittelwert des zweiten Max bei 783µs ist verdächtig.
Lars L. schrieb:> Okay ich glaube ein wenig haben wir uns da missverstanden?
Ja, scheint so. Das Loch in der Verteilung bei 780µs (Verteilung_python)
wird wohl Zufall sein und sich bei mehr Messungen füllen. Wichtig ist
die saubere Lücke um 1200µs (ICtoraspi_all).
Die kurzen Zeiten in verteilung_raspitoraspi sind allerdings verdächtig.
Da stimmt etwas nicht. Wie sieht das Signal auf dem Oszi aus?
> 1552.8666666666666 und zweites Max_mean: 783.2926829268292
Da kannst du viel Datenvolumen sparen. Bei einer Standardabweichung von
50µs und der kleinen Stichprobe sind mindestens alle Nachkommastellen
gewürfelt ;-)
Rainer W. schrieb:> Das Loch in der Verteilung bei 780µs (Verteilung_python)> wird wohl Zufall sein und sich bei mehr Messungen füllen.
Das Loch ist wohl doch kein Zufall. Es entsteht, weil das Signal nicht
symmetisch erkannt wird. Man sieht in dem angehängten Balkendiagramm,
dass dort wo die Datenbits sich nicht ändern, immer abwechselnd ein
langer (z.B. Low) und ein kurzer Puls (z.B. High) erkannt werden (die
Polarität kann auch umgekehrt gewesen sein). Das bedeutet, dass der
erkannte Umschaltzeitpunkt bzw. das Signal nicht symmetrisch liegt.
Außerdem driftet der Wert für diese Asymmetrie über die Messreihe -
etwas merkwürdig, aber zu auffällig, als dass es Zufall ist.
Lars L. schrieb:> Anbei die Flanken mit den Zeiten> Tick: 4193214804, Level: 0, Δt: 894 µs> ...
Üblicherweise dekodiert man Manchester auch nicht mit
Statistikhokuspokus, sondern wesentlich einfacher.
Und wenn die Zeiten in der Statistik eine solche Varianz
haben, taugt entweder der Sender nichts, oder das Gespann
aus verwenderter Hard- wie Software zur Dekodierung.
Eine Erkennung nur nach den Zeiten der Flankenwechsel,
wäre auch sehr anfällig für Bitfehler. Ab einem Fehler
würden die Daten wohl invertiert gelesen...
@TO:
Lies nochmal die Grundlagen der Manchester(de-)kodierung.
Vielleicht fällt dann der Groschen.
Cartman E. schrieb:> Üblicherweise dekodiert man Manchester auch nicht mit> Statistikhokuspokus, sondern wesentlich einfacher.
Wenn für dich Statistik Hokuspokus ist - sorry.
Es geht nicht ums Dekodieren, sondern um die Beurteilung der
Signal-/Erfassungsqualität.
Die Impulslängenverteilung, die in verteilung_raspitoraspi gezeigt ist,
solltest du aber auch ohne großartige Statistikkenntnisse in
Zusammenhang mit Manchester-Code als Unfug erkennen können.
Rainer W. schrieb:> Cartman E. schrieb:>> Üblicherweise dekodiert man Manchester auch nicht mit>> Statistikhokuspokus, sondern wesentlich einfacher.>> Wenn für dich Statistik Hokuspokus ist - sorry.>> Es geht nicht ums Dekodieren, sondern um die Beurteilung der> Signal-/Erfassungsqualität.>> Die Impulslängenverteilung, die in verteilung_raspitoraspi gezeigt ist,> solltest du aber auch ohne großartige Statistikkenntnisse in> Zusammenhang mit Manchester-Code als Unfug erkennen können.
Ich kann dich beruhigen. In meinem Diplomzeugnis steht bei Stochastik
(Statistik inkludiert) eine Eins.
Bei meinen selbst geschriebenen bzw. in Hardware aufgebauten Dekodern
brauchte ich auch keine Statistik. Die funktionierten auch so. ☺
Scheinbar kann eher der TO die Ergebnisse nicht richtig deuten.
(Siehe oben.)
> die Daten lesen kann
Ach, es geht nicht um das Dekodieren?
Cartman E. schrieb:> Ach, es geht nicht um das Dekodieren?
Irgendwann vielleicht schon, aber so wäre das noch vergebene Liebesmüh'
;-)
Da stimmt etwas grundsätzliches nicht.
Lars L. schrieb:> verteilung_raspitoraspi.png
> @TO:> Lies nochmal die Grundlagen der Manchester(de-)kodierung.> Vielleicht fällt dann der Groschen.
Ich verstehe schon die Theorie dahinter. Ich glaube es nützt nichts noch
20x die Wikiseite durchzulesen. Flanke hoch, Flanke runter -> null, eins
-> langes low wechsel auf eins, langes High wechsel auf null. Der Takt
gibt die Entschlüsselung vor was die doppelte freq ist, das vermindert
die Bandbreite. Jetzt absolute vereinfacht gesprochen.
Ich sehe ja in den Daten auch meine halfbits und das zu Datenbits zu
konvertieren wäre auch nicht so dramatisch. Es kommt aber halt nur murks
raus :D Ich kann höchsten mal probieren beim sender auf 14 Flanken Null
zu stellen. und schauen ob ich dann eine Art Sync in den Daten sehe. Das
würde das dekodieren sehr stark vereinfachen.
Lars L. schrieb:> Ich kann höchsten mal probieren beim sender auf 14 Flanken Null> zu stellen. und schauen ob ich dann eine Art Sync in den Daten sehe. Das> würde das dekodieren sehr stark vereinfachen.
Welche Reaktionszeit verspricht denn dein pigio Modul bei
callbacks/ISRs?
Ich persönlich finde ja innerhalb der callback-Routine sowohl das
List.append als auch das print etwas … hmmm … ambitioniert wenn es um
präzises Timing gehen soll.
Man könnte ja erst einmal ein bereits vordefiniertes array füllen und
anschließend – nach Empfang – die Werte in einem Rutsch ausgeben.
Hallo Nobert,
das hatte ich mir auch mal überlegt, da ich nur den Pi Model 1B habe.
Aber habe auch da gelesen das der PI ca. min. 250khz Schaltzeit hat und
wenn ich nach der Webseite gehe hat die Library gehe.
Ob Python das ganze mit macht kann ich nicht sagen.
https://abyz.me.uk/rpi/pigpio/python.html
1
Settings
2
A number of settings are determined when the pigpio daemon is started.
3
o the sample rate (1, 2, 4, 5, 8, or 10 us, default 5 us).
4
o the set of GPIO which may be updated (generally written to). The default set is those available on the Pi board revision.
5
o the available PWM frequencies (see set_PWM_frequency).
Lars L. schrieb:> da ich nur den Pi Model 1B habe.
Jupp, so einen habe ich auch. Single core 700MHz glaube ich. Gerade
Bildschirm- oder USB-Ausgaben schnupfen da natürlich Rechenzeit auf.
Wobei, wenn die 5µs garantieren können, dann sollte es keine Probleme
geben.
Edit:
Du könntest in:›/etc/security/limits.conf‹
einen Eintrag hinzufügen,
1
norbert - nice -11
welches einem spezifizierten user erlaubt, einen Prozess mit höherer
Priorität laufen zu lassen.
1
nice -n -10 <application>
Vielleicht lindert es die single-core Leiden bei dir auch ein wenig.
Lars L. schrieb:> Ich sehe ja in den Daten auch meine halfbits und das zu Datenbits zu> konvertieren wäre auch nicht so dramatisch.
Die Pulsbreiten in verteilung_raspitoraspi.png sind völliger Mist. Was
willst du da dekodieren?
Was soll das für ein Signal sein?
Rainer W. schrieb:> Lars L. schrieb:>> Ich sehe ja in den Daten auch meine halfbits und das zu Datenbits zu>> konvertieren wäre auch nicht so dramatisch.>> Die Pulsbreiten in verteilung_raspitoraspi.png sind völliger Mist. Was> willst du da dekodieren?> Was soll das für ein Signal sein?
okay, habe mir nochmal die Webseite angeschaut und Analog zum cpp
programm für den Raspi das Python-Programm gefunden. So wie ich es
verstanden habe berechnet das Programm die Grenzen selber btw breite der
Signalflanken. Die Ausgabe für die Flankenlevel scheinen auch nicht zu
stimmen, also kann man danach auch nicht gehen. Deswegen hatte ich jetzt
versucht Sketch vom AVRTiny anzupassen.
Ich sende am Ende ein langes über 5ms low, dies soll den Abschluss
definieren. Das Pythonprogramm von der Webseite registriert dies auch
und kann mir den aktuellen GAP zeigen.
if edge_len > 5000 and edge_len < 10000: # 5000 us, 5 ms.
5
print("Parameter edge_len: ", edge_len)
6
if self._in_code:
7
print("erkanne Bits: ", self._bits)
8
if self.min_bits <= self._bits <= self.max_bits:
9
self._lbits = self._bits
Wenn ich nun vom anderen Raspi die Daten sende wobei da definiert ist
mit t0=300 und t1=900 erhalte ich folgende Ausgabe.
Empfänger:
1
Parameter edge_len: 8990
2
erkanne Bits: 24
3
code=5 bits=24 (gap=9016 t0=319 t1=879)
4
Timing: 315 E1: 880
5
Parameter edge_len: 8985
6
erkanne Bits: 24
7
code=5 bits=24 (gap=8990 t0=328 t1=871)
8
Timing: 325 E1: 880
9
Parameter edge_len: 8985
10
erkanne Bits: 24
11
code=5 bits=24 (gap=8985 t0=333 t1=866)
12
.....
13
Parameter edge_len: 8916
14
erkanne Bits: 24
15
code=5 bits=24 (gap=8925 t0=355 t1=844)
16
Timing: 330 E1: 874
17
Parameter edge_len: 8950
18
erkanne Bits: 24
19
code=5 bits=24 (gap=8916 t0=360 t1=840)
20
Timing: 344 E1: 857
21
Parameter edge_len: 5240
22
Timing: 319 E1: 826
Sender:
1
./_433D -t 17 4 4 4 4 4 4 5 5 5 5 5 5
2
sending 4/24
3
sending 4/24
4
sending 4/24
5
sending 4/24
6
.......
Wenn ich mir das so anschaue, sind die Zeiten nie wirklich gleich obwohl
ja die Doku meinte 5 microsekunden genaue Abfrage.
Ich komme scheinbar mit dem Sketch vom Tiny nie in den richtigen Timing
Bereich vom Raspi Programm. Den die Variable self._bits wird immer nur
mit 1-2 bits gefüllt. Wie Rainer meinte das wird wohl ein großes Timing
Problem sein.
Hallo zusammen,
ich bin ein bisschen weiter gekommen.
Mit der Bibliothek RC-Switch https://github.com/sui77/rc-switch/ hat die
Datenübertragung Out-of-Box funktioniert. Zwar erstmal nur das
C-Programm von der Webseite aber mit ein paar Anpassungen dann auch das
Python-Programm. Hauptsächlich habe ich die Methode _calibrate
angepasst.
1
tio = float(self._t1)/float(self._t0)
2
#print("verhältnis: ", ratio)
3
if ratio < 1.3: # original wert 1.5
4
self._in_code = False
5
6
slack0 = int(0.5 * self._t0) # original 0.3
7
slack1 = int(0.5 * self._t1) # original 0.2
Eine weitere Bibliothek wäre TinyRF für Tiny85
https://github.com/pouriap/TinyRF, lief nicht ganz so sauber auf meinen
Digispark Clone. Es muss wahrscheinlich noch ein wenig angepasst werden.
Ich versuche in den nächsten Monaten eine Art C-Code zusammenzubekommen.
Denn die Bibliotheken sind Arduino und dadurch recht groß. Ich habe zwar
auch ein bisschen Code hier im Forum gefunden hat aber er hat leider
nicht funktioniert.
RC-Switch: ca. 21%
TinyRF: ca. 9%
Thread beobachten
Seitenaufteilung abschalten