Annak most nem vágnék neki, (lib javítás).
Akkor mindegy, hogy 4-5 vagy 0-1 lábról megyek ha nem állok neki javítgatni?

Már leírtam! Ez igy maradt SoftWare serial!
Csak elfoglalja a HW serial portott, ami valószinüleg kellet másra!
Pl. debugolásra, softver feltöltésre?

Értem, köszönöm a segítséget.
Egyéb lehetőségnek még ezt találtam: Bővebben: Link

Ez is SoftSerial.
Csak külső Portokkal megtámogatva.
Ez által meszebbre ilvihető, mint a TTL-serial.

Ezzel sem lenne stabilabb a kommunikáció?

Mi a hiba HW vagy SW jellegű? Mért nem stabil?

Lehet, hogy a nagy frekis rádió összekötetésnél van a hiba?
Nem hiszem, hogy a serial rész a hibás?
???
Ezt mind tisztázni kellene!

Kiolvasom a kapott SMS szövegét és adatit a SIM modulból, én néha (mondjuk 20-ból egyszer), kerül bele egy téves karakter vagy kocka. Ennek akkor van jelentősége ha a telefonszámban, vagy a parancsban van a hibás karakter, mert akkor nem hajtódik végre.
Szerintem, ez pár % hibát eredményez, ha van lehetőség rá ezen szeretnék javítani, ha nem sikerül, akkor ezzel is elégedett leszek.

A Sim800l-asnak adáskor, kevés az USB-s /Arduino(A) tápja !

Akkuról megy, külön tápja van a sim-nek, meg az arduinonak is.

Én ís próbálkoztam Sim800l-al.
Nem voltam elégedet vel!
Ezért Fiók Project maradt!

Ilyenkor hibajavítást (újra küldést) kérsz!
Erre való a kétirányú kapcsolat.

Utána nézek van-e olyan parancs amivel újra tudom küldetni a sim-től érkező utolsó küldést.

Újraküldő parancsot nem találtam sajnos. Marad első körben az eredeti felállás.
Köszönöm a segítséget.

Sziasztok!

Lenne egy mérleg szenzor, ami 9-12V-ot igényel. Ez valami ipari szenzor, így nem 5V-os. Bővebben: Link
Ennek az Adatait szeretném leolvasni Arduinoval.

Kérdés, hogy miként tudnám ezt rácsatlakoztatni? A HX711 is csak 5V-ot igényel.

Üdv!
Egy ili9325-ös érintőképernyős kijelzőhöz szeretnék valamiyen magyar nyelvű dokumentumot kérni.
Az interneten csak angol myelvű van, amiből nem sokat lehet érteni.
Előre is köszönöm!

Szerintem nyugodtan megtáplálhatod 5V-ról, a kijövő hasznos jel úgy is differenciális. Az ADC után kell majd átszámolnod a megfelelő súlyra a kapott értéket, itt akkor 10mV lesz a végkitérésed (2mV/V a meredeksége).

Szia
Csak most olvastam amit írtál ha még nem sikerült megoldani én is bajlódtam vele már. Nekem az usb csati ki volt hosszabítva és azért nem látta a progi, összedugod azzal a kábellal amit kaptál hozzá közvetlenül a gép usb-be és jó lesz

Gondoltam erre én is, mert ez a Nano Mini USB csalakozós, az eddigi lapjaim pedig USB-B-sek voltak, viszont nem adtak hozzá kábelt, emiatt vettem egyet a boltban. Lehet azzal van baja, mert kb. 1,5m, nem a megszokott 30 centis. A programozást már megoldottam az ICSP headerjén keresztül egy Megával, de érdekel, hogy tényleg ez okozta-e. Szerzek majd egy másikat, és letesztelem.

Nekem az okozta de egy rövidebb teló kábel még jó kb 50 cm

Sziasztok!
Van egy arduino nanom.
Egy meglévő programomat bővítettem kicsit.
Vagy egy neopixeles (16db) amimáció kezelés is benne amit idők összehasonlításával időzítek a megfelelő ütembe. Van hogy 2 lépés között mondjuk csak 50ms van.
Tegnap azt vettem észre hogy az egész időnként beszaggat. Van hogy az animáció fél/1 másodpercre is megáll.
Érdekes, hogy ha fogtam és újra feltöltöttem akkor meg nem.
(komolyabban nem tudtam ellenőrizni hogy kicsit később nem szaggat e be újra az újratöltés után is, mert már nagyon fáradtt voltam)
Mi lehet a gond?
Az az +3 lépés ami az animációnál van, ami egy plusz pwm-et is állít, nem hinném hogy ennyire kéne befolyásolnia.
Előre is köszi.

Csináltam egy külön próbakódot.
Miért van hogy a loop eső mérésekor nagyságrendekkel többet mér?


Eredmény:
...writing 0: 376
...writing 1: 0
...writing 2: 0

Ha a setup végére teszel egy 1 másodperces delay-t akkor is ez az eredmény?

Igen.
De nem csak az első ciklusban hanem ahányszor a loop() lefut mindig az első mérés eredménye nagyos rossz.

Lehet emiatt van, hogy a programom ami miatt volt a teszt elkezdett belassulni.
Ajánlottak valami időzítőket amivel pontosan tudnék ütemezni, mondjuk 5ms-oonként, és akkor nem lenne csúszás. Csak oldjam meg, hogy két művelet nem üsse egymást.
Sajnos nem találtam erre az időzítésre (amikor nem egy lábon lefutó jel csinál interrupt-ot) semmi használhatót.

Ha jól számoltam, akkor így 5 ms-onként kapsz egy megszakítást. Megszakításkor az fog lefutni, ami programot beleírsz.

Setup-ba:
TCCR1A = 0;
TCCR1B = 0;
TCCR1A = _BV(WGM11) | _BV(COM1A1);
TCCR1B = _BV(WGM13) | _BV(CS11) | _BV(WGM12);
ICR1 = 10000;
OCR1A = 5000;
TCNT1 = 0;
TIMSK1 |= (1 << OCIE1A);

A megszakításod függvénye:

ISR(TIMER1_COMPA_vect){
//programod
}

És ha a timer1-et már másra használja az Arduino? Akkor majd az nem fog működni. De legalább lesz 5mS-ként interrupt.

Abban az esetben át kell írni a timer2-re. Persze ha az is használva van már valamire, akkor bukta.
De egyenlőre nem tudjuk, hogy a timereket miként használja.

Kipróbáltam a kódot, nálam (új, most bontott nano) mindenhol 0 amit ír.
A millis()-eket micros()-okra átírva 4 vagy 0 us a ciklusidő, kb. 3 futásból 1x mindegyik 4 us, a másik két esetben az egyik 0 us (változó, hogy mikor melyik.
Ha az a0, a1, a2 változókat átírom long-ra (mert azt írok bele), akkor sokkal ritkábban, kb. 6-8 esetből 1x valamelyik 0 us, a többi esetben 4-4-4 us.

Arduino 1.6.5 alatt próbáltam, és ez az átírt kód amiről beszéltem:

Azt tudni kel, hogy a timer megszakítások 4uSec-enként következnek be.
Ennél sűrűbb megszakításkérés esetén, már a UC-nek nem lenne ideje mást is csinálni.

Szerintem ilyen rövid for ciklus idejét nem is érdemes mérni! (Valahol ott lehet az érzékelés határán!)

Nyilván így van, csak a kollegának sikerült párszáz millisec ciklusidőt tapasztalnia (ugyanígy nano) millis() használatával. Ezért néztem meg, hogy micros() esetén tapasztalok-e jelentős eltérést, még ha nem is ekkorát. De nem.

Ha rossz változó deklarálást használsz long- unsigned long ( a millis() unsigned long) , a változó egy részét hasonlítod csak össze. Lehet ez (is) a bajod.