THEMA:

Hallo Alex,

komme die Tage "zu nix", habe aber trotzdem nebenher ein wenig nachgedacht. Dein Vorschlag würde wohl schon funktionieren, es entsteht aber das Problem, dass während die Low-Prio-Senoren übertragen werden, keine Hi-Prio-Sensoren zum Zug kommen.

Um das zu vermeiden, muss man den Low-Prio und Hi-Prio-Datenversand ineinander mischen.

Die Herausforderung dürfte sein, dass man dem Library-Benutzer eine einfache Steuerung für Low- und Hi-Prio geben sollte. Deine Idee mit ID>15 ist "low" und ID<15 ist "hi", ist schon nicht schlecht. Alternativ könnte man auch zwei Sensorlisten definieren. Eine davon enthält die hochprioren Sensoren, die andere den Rest. Oder man führt in der Sensordefinition ein "Hi-Prio-Attribut" ein.

Nun muss man sich auch noch überlegen, was bedeutet Hi-Prio und Lo-Prio ? Von meinem Gefühl aus würde ich sagen: Hi-Prio ist "so oft wie möglich", Lo-Prio ist "so selten wie möglich". Hier wäre es interessant, was Ihr für konkrete Anwendungsfälle habt, in denen das heutige System nicht optimal ist.

Man muss nun steuern, in welchem Verhältnis die Sensorwerte gemischt werden. D.h. auf wieviele Hi-Prio-Werte kommt ein Low-Prio-Wert. Von diesem Steuerwert hängt es ab, ob man die Low-Prio-Werte noch so oft transportiert, dass die Anzeige nicht zu blinken anfängt. Der Steuerwert ist natürlich auch abhängig davon, wieviele Sensorwerte es überhaupt gibt. Gibt es zu viele Hi-Prio-Sensoren oder ist der Steuerwert für die Mischung unpassend, geraten die Low-prio-Sensoren vielleicht in den Timeout (Anzeige blinkt).

Damit können wir in die weitere Diskussion über die Priorisierung einsteigen. Ich freue mich auf rege Beteiligung .

Viele Grüße
Bernd

Hallo an alle Arduino Spezialisten,

Ich habe mir alles bestellt was ich für die RFID-Battery App benötige nur leider habe ich noch keine Ahnung von Arduino das mit Lua ist nicht das Problem aber Arduino benötige ich bitte bitte eure Hilfe. Wie fange ich damit an auf was muss ich achten usw. Wäre klasse wenn jemand ein Viedo erstellt hat oder mich einfach mal anruft oder ich melde mich. Bin für alle Tips dankbar. Bin auch bereit euch bei Skripten weiter zu helfen bei bedarf.
Arduino Pro Mini 3.3V 8Mhz
RC522 13.56Mhz RFID-reader/writer
2.4kΩ resistor
Servowire and plug
For programming the arduino you also need a USB to TTL adapter.
Anti-metal RFID-tags recommended!

Ps. Hoffe ich bekomme das ohne Hintergrund wissen hin....


Mit freundlichen Grüßen
Thorsten

Hallo Thorsten,

meine "Bauanleitung" für den WirelessBIDWirelessBID kennst du vermutlich.
Ist ja Teros Sensor von der Hardware her fast identisch.
Du benötigst halt einen USB-Seriell Wandler, damit man den Code auf den ProMini transferieren kann.
Die Treiber installieren sich selbst, wenn es ein FTDI-Baustein ist. Dann muss in der Arduino IDE (Entwicklungsprogramm, frei zu laden) nur noch der Prozessortyp und Taktrate sowie der Port des Wandlers angegeben werden und man kann den Code kompilieren und danach transferieren.
Die Funktionen sind in einer gesonderten INO-Datei ausgegliedert. Die muss dann als separater Tab neben dem Hauptprogramm stehen, sonst meckert der Compiler.

Ansonsten gibt es viele Einsteigervideos für die Thematik. Ist ja der C64 des 21 Jahrhunderts neben dem RaspberryPi.
Solltest du noch weitere Probleme haben, mach aber besser einen extra Fred hier auf, weil es hier mehr um die Funktionsbibliothek von Bernd geht.

Gruß
Onki

Hallo zusammen!

Ich bekomme das Beispiel JetiEXSimple einfach nicht richtig zum laufen!


Ich habe

Arduino Uno
Arduino mini Pro 3,3 V 8 Mhz
Arduino IED Version 1.6.6
Jeti R5L (EX) Empfänger Version 3.23
Jeti REX6 Empfänger Version 1.0
Jeti DC 16
Jeti JetiExSensor Lib 0.96 02/21/2016 Steht in der .ino


Mit einem R5(EX) Empfänger läuft der Beispiel Sensor mit dem UNO und dem mini PRO!
Die Sensoren werden nach dem Starten in der DC 16 (Sensoren/Aufzeichnungen) mit der Taste ‚AUTO’ mach ca. 20 sec. Aufgebaut.
Ist das schon mal so OK? ( das ist aber ja kein Problem)
Mit einem Unisens geht das in 5 sec.

Mit dem REX6 werden einige der Sensoren, wenn überhaupt, erst nach Minuten
aufgebaut!(dann aber eventuell nur 2 oder 3)!

Wenn ich mir bei einem Sensorwert die Laufzeit Sekunden des Arduinos „Millis()/100“ anzeigen lasse, Sehe ich, das beim R5 mindestens jede halbe Sekunde ein Wert in der DC 16 angezeigt wird!

Wenn ich nun auf den REX 6 wechsele (die Sensoren sind ja noch vom R5 aufgebaut)
Wir meistens nur jede 2 Sekunde eine neuer Wert Angezeigt!

Habt Ihr auch solche Erfahrungen gemacht?
Was kann ich wo ändern damitt das auf allen Empfängern läuft?

Gruß Micha

Hallo Micha,

die Sensor-Header-Daten, die der Sender zur Erkennung der Sensoren braucht, werden in meiner Library relativ selten gesendet. Sie werden sozusagen innerhalb der ersten Telemetrie-Pakete "eingestreut", erst nach 256 Paketen passiert das erneut. Wenn der Sender die Daten "verpasst", geht es recht lange bis der Vorgang erneut stattfindet. Sollten die Daten also nicht innerhalb von 20 Sekunden angezeigt werden, muss erneut "Auto" gedrückt werden.

Dass das Ganze langsamer als beim Unisens geht, mag 2 Gründe haben:

1. Die Sensor-Header werden nur "eingestreut", d.h. sie kommen nur in jedem 2. Paket. Hier wäre noch Optimierungspotential.
2. Die Pakete werden nur alle 150ms verschickt. Je nachdem, ob der Aufruf von "DoSend" in der Loop()-Routine oft genug dran kommt, wird noch seltener gesendet (vielleicht weil der Code auf den Messwert eines Sensors wartet).
Das minimale Sendintervall kannst Du hier verkürzen. 100ms wäre ein Wert, der sicher noch geht.

uint8_t JetiExProtocol::DoJetiSend()
{
// key handling
m_jetiKey = m_pSerial->Getchar();

// send every 150 ms only
if( ( m_tiLastSend + 150 ) <= millis() )
{

Zu Deinen Problemen mit dem REX6:

Ein User hat berichtet, dass er seine Baudrate für die REX-Empfänger auf 9700 eingestellt hat. Vielleicht ist das Timing beim 8 MHz-ATMega328 gerade grenzwertig.

Du kannst in JetiExSerial.cpp mal den Wert auf 9700 ändern:

#elif F_CPU == 8000000L // for the 8 MHz internal clock (Pro Mini 3.3 Volt)
unsigned int ubrr = F_CPU / 16 / 9600 - 1;
UBRR0H = (unsigned char)(ubrr>>;
UBRR0L = (unsigned char)ubrr;
#else

Bitte melde zurück, ob das hilft.

Viele Grüße
Bernd

Hier wird auch von 9800 Baud geredet:

j-log.eu/jlog-in-funktion/telemetrie/jeti-v1-und-ex/

Beim 8 MHz ATMega328 haben 9600 und 9700 Bit/s die gleichen Konstanten (0x31).

Daher würde ich den Code so ändern:

#elif F_CPU == 8000000L // for the 8 MHz internal clock (Pro Mini 3.3 Volt)
UBRR0H = 0;
UBRR0L = 0x32; // 9800 bit/s
#else