Tárgytalan, isp-t elfelejtettem feltölteni az ardura

Sziasztok.
Valaki próbálata összerakni ezt a projektet?
Nekem nem akar sikerülni pedig mindent jól kötöttem össze, az arduino betölti, de meg sem mukkan.

Köszi, hogy elolvastad.

Szia!
Ezt még konkrétan nem, de volt már próbálkozásom két ultrahangos szenzorral. A két szenzor képes egymást bezavarni. Mindenképpen úgy csináld, hogy mérsz az egyikkel, vársz egy kicsit, utána mérsz a másikkal. Mivel ez a módszer nekem túl lassú volt, ezért elvetettem.

Köszi aválaszt.
... és megoldást találtak. Ezt hozzá kellett tennem:

#define HARDWARE_TYPE MD_MAX72XX::GENERIC_HW
majd módosítsa ezt az
MD_MAX72XX mx = MD_MAX72XX (CS_PIN, MAX_DEVICES);
ehhez
MD_MAX72XX mx = MD_MAX72XX (HARDWARE_TYPE, CS_PIN, MAX_DEVICES);

Félig már jó, mivel csak az egyik kijelző mutatja a szemet, de külön tesztelve mindkettő működőképes.

Még gyakorlatozok vele.
Kössz.

Sziasztok. Egy 15 km kábelt kellene figyelnem (a végén egy pár szál áthidalva, és a másik végén figyelve), megszakadáskor kuldjön SMS-t. Bővebben: Link Összeraktam ezt, 7es pint átirtam HIGH-ra, hogy akkor küldjön sms-t mikor szakadás van, ne mikor gombnyomás. Teoretikusan ha GND-t elveszem a 7-es pinről, küld SMS-t. Fog ez működni reálisan is? KB 900 ohm a kábel ellenálása mérve. Előre is köszönöm a segitseget.

Nem, a kontroller lábára egy méteres vezetéket sem kötnék, csak valami relé vagy opto leválasztással.

Maga a kód működhet..., viszont 15km vezeték már tekintélyes antenna is lehet(nem írtad le a jellegét, árnyékolt? Csavart érpár e?), mindenképpen erősen javasolt megszűrni AC-ban! Ha levegőben van a kábel, akkor a villámlás ellen is védeni kell a bemenetet....

A kábel levegőben, földön is megyen, 3x4x0,8 telefon kábel, nem árnyékolt, de 4 esével vannak csavarva. Relé jó ötlet, azzal fogom megpróbálni. Villámlás ellen védve van. A kód működik. Azt jól csinaltam hogy ne külldözgesse az smst minden pillanatban, hanem csak 12 óránta, végén átírtam a delay értéket. Fog működni?

A kód itt a legkevésbé kritikus! De ha már kód..., nem szerencsés 12 órára(!) megakasztani egy függvényt delay-al! Inkább csak rövid időre tedd ezt, minek után növelsz mindig egy számlálót. Amikor a számláló eléri a kívánt időmennyiséget, akkor küldöd az sms-t. Így nem fog a program futása megakadni órákra egy várakozás miatt...

Nos ha értenék hozzá akkor megtudnam írni. De lehetséges hogy utánanézek.

Borítékolható, hogy kábellel nem fog helyesen működni. Legalább 2 alapvető szabályt sért a megoldás, az extrém hosszú Delay-t már nem is említve.
Az egyik, hogy processzor kivezetést nem szabad használni panelen kívül perifériának. A másik, hogy a tápfeszültségére ugyanez vonatkozik, azaz a processzor tápját sem szabad "messzire" vinni. A lényeg, hogy alapvető hardveres problémák vannak. De a program sem erre van kitalálva. A minimum egy jel hossz vizsgálat kell oda, nem pedig az első impulzusra már küldeni is az SMS-t.

Talán a régi telefon hálozatokben bevezetett technologiát kellene elővenni. Egy fix áramot kell a kábelbe küldeni, és azt mérni a procival, akár egy optokoplerrel vagy hasono elemmel.
Ez kizár sok zavart és aránylag biztonságosan jelzi a kábelhibát.

Delay() helyett Millis() fuggvényt kell használni.
Millis túlcsordulását is megkell oldani (20-40 nap között rémlik a kb.: 4milliárd millisec )
De ez ismert és megoldott programozási fogások.

Hosszú drótot optocsatlóval lenne érdemesebb figyelni.
Relé is jó lehet ... csak a fogyasztás már kritikusabb , ez jó lehet áramszünet jelzésre is , mert akkor is kialszik a led , elenged a relé.
Esetleg több led nagyobb fesz is mehet a dróton át és fényellenállás vagy optotranzisztor ez érzékelőoldal.

Sziasztok!

Jellemzően 24-26-os AWG kábelezést használok az Arduinos kütyüimben. Általában a be-tápot kapja ezeken keresztül. Viszont mindig tartottam attól, hogy túl hosszúra méretezem a kábelt.

5V esetében milyen hosszú kábelt használhatok biztonsággal szerintetek? Ahol nem esik kvázi érzékelhetően a feszültség. 60cm még beleférhet?
Illetve ugyan ez érdekel olyan esetben is, amikor a kábelen adat érkezik.


Továbbá rendeltem egyILYEN kapcsolót. Ezen érzékelhető feszültség esés ?

Hogyan tud túlcsordulni ha nekem mondjuk 12 óránta kellene küldenie az SMS-t? Nem igazán értem, programozásban nem vagyok otthon.

A millis() függvény működéséből adódóan , mert azt számolja , hogy uC hány msec óta van tápfesz alatt.
Ezt 32 bites változóban tárolja el.
Ha ez túl csordul akkor 4milliárd (2^32) millisec telt el.
Ekkor újra 0 lesz a 32 bites változóban.
Általában az előző millis() értékét hasonlítjuk össze a kívánt következő időzítés értével.
Ha eltelt annyi idő (amit időzíteni kellett)akkor az aktuális millis() lekérdezésekor a feltétel végre hajtja a kívánt utasítás részt. Ha nem telt el .. tovább fut a másik ágon a program.
(sok miliárd meg egy kicsi(kívánt időzítés értéke msecben) az kicsit többmint ... de ha meg túl csordul akkor meg nagy sokára lesz (40nap) megint ez az érték közelében (kicsivel 4 milliárd előtt), mert 0 tól kezd számolni.
A millis() lényege , hogy ezzel párhuzamosan tudsz időt mérni, és nem függeszted fel a program futását mint a dealy() esetén.
Delay használatánál amíg a delay nem jár le addig semit se fog végezni a program ott csak "1 helyben topog". Ezért nem fog tudni bármely mást is végezni a proci .
(reset /tápfesz elvétele újra indítja programot )

De nekem nincs is szükségem semmi másra. Figyeljen non-stop, ha kábelszakadás van küldjön egy SMS-t. 12 óra múlva nézze meg, hogy van-e még kábel szakadás, ha van SMS, ha nincs akkor folytatja a kábelszakadás figyelését.

Nehéz erre válaszolni, mert nem igazán vannak paraméterek. Mi számít "kvázi érzékelhető" felszültségesésnek?
Illetve a feszültségesés az U=I*R képlettel számolható, pontosabban ennek a duplája, mert ugye mindkét a föld és az 5V kábelén is ennyi esik. Az I-t mi nem ismerjük, az R pedig a kábel függvénye, tele van a net táblázattal és kalkulátorral. Ja, és az AWG26 ellenállása kb. duplája az AWG24-nek, szóval szó szerint semmilyen paraméterünk nincs, amiből ki lehetne indulni

De mondjuk az AWG26 ellenállása 0,134 Ω/m (első netes találat, ha nekem kellene megnézném még pár helyen), TFH 100 mA a uC és a ráaggatott dolgok fogyasztása, ez esetben
U=2*0,6m*0,134 Ω/m*0,1A ≈16 mV feszültségesés.

Hosszú távra nem használunk millis()-t, pont a túlcsordulás miatt. Timer alapú időzítés kell helyette.

Lehet használni, csak le kell kezelni a túlcsordulást.

Ne keverjük az így is működik és a korrektül elkészítettet.

Épp azt magyarázzák, hogy ha megáll a program a delay miatt, nem tud figyelni sem.
Tehát úgy képzeld el, hogy ha becsukod a szemed 12 órára, addig semmit nem látsz.
Ha letelt a 12 óra, kinyitod a szemed pl 1 ms időtartamig, és látod, hogy kábelszakadás van.
Ekkor tudsz SMS -t küldeni. Ez után 12 óráig megint csukott szemmel vagy, és semmit nem látsz.

Lehet hülye hasonlat, de ez a lényeg.

A CPU sem tud addig ellenőrizni, míg a delay -od le nem jár. Ha lejárt, elvégez egy ellenőrzést, és vagy küld SMS -t, vagy nem, aztán újra várakozik 12 órát. Ha neked így jó, lelked rajta...

De programozói szempontból ilyet soha nem csinálunk. Sokkal inkább megszakításkezeléssel érdemes megoldani, úgy azonnal küldi az SMS -t, amint a szakadást keletkezik, azonnal érzékeli.

Így is egyből érzékeli a szakadást. Ha már egyszer ellopják a kábelt, utána már vissza nem viszik.

Ha számít a rendelkezesre allas akkor felnaponkent tudni , hogy havaria tortent akkor azt lehetne nyomvonal bejarokent is ellenorizni avagy arra tevedo turistakent ...vegulis az igenyekhez kell igazitani a megvalositast.

Rossz a hasonlatotok..., a program nem 12 óránként figyel egy pillanatra, hanem folyamatosan figyel, ha esemény volt, úgy azonnal sms-t küld, majd 12 órára pihen. Aztán újra elkezd figyelni folyamatosan....

Szerintem a legegyszerűbb az, ha mondjuk másodpercenként ellenőrzi a szakadást (így nem akasztja meg nagyon a dolgot), és ha sms-t kellett küldeni, utána már nem küld többet a javításig.
Így mindenkinek jó lehet a szájíze

Azon is bukhatsz, a bemenetet rendesen kell szűrni, mert a kábelnek az az alaptulajdonsága, hogy minden zajt összeszed. Ez ellen hardveresen és szoftveresen is védekeznék. Programozásilag, megnézném hogy szakadt e a kábel, ha igen várnék valamennyit, ha még mindig szakadt, akkor nyilvánítanám szakadtnak. ( lehet cifrázni, ha szakadt, de megjavul, akkor az időzítő újra indul. Ha az időzítő lejár, akkor szakadt a kábel) de az első megoldás az a minimum.
( igaz nem kábel volt, de két szál vezeték egymás mellett 20-30m kihúzva, annyi zavart összeszedet, hogy egy érzékenyebb jelfogó meghúzott róla néha )

Ha már sok sok méter drót ... az már "tápvonal hálózati" jellemzőkkel bìr.
Ismerve a frekvencia függő jellemzőit , beépíthető lenne egy ilyen " mérőmű".
Ekkor nem is folyamatos DCvel kéne rajta vizsgálódni hanem ACvel.
Impulzusokkal, nem rövidre zárni ... mivel tápvonal ... inkább a hullámimpedanciájával zárni le.
Mérő impulzusokkal (időnként fél 1 2 óra) ellenőrizni.
Ezekkel nem csak azt tudnád meg hogy szakadt vagy nem ... hanem azt is , hogy hány (k) méterre van a szakadás helye.

Szia, mivel Arduino, én is a millis függvényt tartom idözítéses feladathoz helyesnek. Itt tárgyaltunk már a túlcsordulás problematikáról.

Ahogy én látom, itt ketté ágazik a történet: egyfelől van a szoftver réteg amiben vagy tudunk segíteni vagy nem, másfelől pedig itt a tápvonal kérdése, ami szerintem bőven tartogat még megbeszélni valót engem is érdekelne a hogyanja. Talán megérdemelne egy külön témát! Kera_Will, tudnál erről bővebb kiejtést adni? Hogyan szokták ezt? Esetleg másik témában..