# Elektronikas forums >  Pulksteņu laiku sinhronizācija

## sasasa

Turpinot tēmu Bezvadu savienojuma varianti , bet nejaucot prioritātes, turpināšu šeit.
Interesē varianti caur radiokanālu, līdz 100m (80m ar 100% garantiju) attālumam nosinhronizēt vairākus (2-3) pulksteņus/taimerus.  Viens no tiem uz ESP8266 , bet vēl 2 vai nu uz Arduino Nano vai arī ESP8266 Tas jāpaveic telpā, tātad GPS sinhronizācija laikam ka atkrīt. Jāsinhronizē tikai savstarpēji un ar reālo laiku nav nekāda sakara.  Google likās visai skopa šajā jautājumā. Ja der, tad izmantojam nRF24L01 vai SI4432 vai , ja tie neder, tad kas cits.

----------


## Jurkins

Par nRF nepateikšu, bet ar SI4432 čipu gan. Ar vienu raidam kaut ko vienalga ko, uz citiem nokonfigurējam GPIO0 (pārejās parasti ir aizņemtas ar TX/RX obvesa pārslēgšanu) izdot pārtraukumu "Valid Preamble Detected". Domāju, ka tas notiksies visiem vienādi ...+/- korekcija uz attālumu un gaismas ātrumu.

----------


## sasasa

> Domāju, ka tas notiksies visiem vienādi ....


 Mani šobrīd interesē cik tas "vienādi" ir skaitļos. korekcija uz attālumu ir sū.., tā būs konstanta un man nemaisa, bet vot nostrādāšanas ātrums no signāla saņemšanas līdz apstrādes beigām ir kritisks.  Ja man būtu tie modulīši, tad jau nomērītu, bet tā ka nav, tad pirms pasūtīt un gaidīt, būšu priecīgs, ja kāds varētu nosaukt kādus skaitļus.
Anyway paldies par idejām!

----------


## JDat

Aizmirsi piebilst cik precīzi jānosinhronizē.

Var sinhronizēt da caur jeb ko. Silab, Nordic semicon, Hope RF, Aurel, IR gaisma, LEDs, slotas kāts (pēdējie 2 ir sarkasms). Vajadzīgo pasvītrot. Problēma nav moduļos, bet gan tajā, ko gribi panākts un kāda kļūda ir pieļaujama.

----------


## sasasa

Nav man saprašanas cik kas izmaksā un kādas pūles jāpieliek katrai konkrētai precizitātei.  IR nebūtu īpaši ērti. 
Varētu mēģināt sākt ar  < 5us, bet viss atkarīgs no izmēriem, cenas un laika patēriņa. Ja var bez lielas piepūles zem 1us , tad jo labāk. Ja stipri sarežģīti, tad var provēt arī ar >5us
Priekš manis ideālā variantā sinhronizācijas signālu raida no "bāzes" ar to pašu moduli ar ko tiek pārraidīti/saņemti pārējie dati, lai nav jāapkarina ar papildus moduļiem. Ja tas neiet cauri, tad liekam klāt papildus, kas nepieciešams

----------


## JDat

Bet kāpēc jābūt tādai precizitātēi?

ir divas idejas:
1) Izmantojam tādu pašu principu kā NTP. Algoritms paliek, bet realizācija vienkāršāka.
2) Iedomājies situāciju: Raidītājs sūta pliku ON/OFF (OOK modulācija vai FSK). Uztvērēji lokāli ar taimeri skaita savas mikrosekundes. Brīdī kad pazūt sigānls (transition to low) uztvērējs piefiksē sava taimera stāvokli. Nosuta cikos saņema signālu no raidītāja un piegriež savu lokālo pulksteni. Raidītājs apstrādā datus un nākošreiz sūta transition to low nedaudz ātrāk.
Tāda fiksā vakara ideja. Reakcijas latenci tas tas neizslēdz bet sasinhronizēt varētu ar +/- 4 AVR clk precizitāti. Tas ir mazāk par 1 uS pie takts frekvences 16 MHz. ESP? Da hren viņu zin. Es, kā jau meža dīvainītis, izmantotu Propeller MCU un kādu transīveiri, kuram bez SPI/UART/I2C vēl var arī lasīt raw datus no pina. Ja nemaldos, tad SiLabs tam ir stipri piemērots. nRF? Jāpēta.

----------


## Jurkins

Ar arduino  īsti nedraudzējos, tāpēc nesaslēgšu un nesaprogrammēšu uz ātro, un arī tad baidos, ka ar to micros() lieta aizies  auzās. Bet, ja izmanto 3 modulīšus, tad abi uztvērēji jau nu gan saņemtās paketes apstrādi beigtu (nu pietiekoši) vienlaicīgi. Tādam SI jau nu toč pietiktu saņemot valīdu paketi (da jebkādu, kaut 1 baitu) nonullēt pulksteni. Varbūt var līdzīgā veidā ar nRF, raidīt kaut ko un kad saņemts tas zināmais kaut kas, nonullēt pulksteni. Nez vai čipam no čipa redzami atšķirsies apstrādes laiki.

----------


## JDat

Jurkin! Kā zināt cik uS pagājis no brīža kad tu pabeidz SPI sarunu ar raidītāju līdz brīdim kamēr uztvērējs norausta interrupt kāju? Tas ir laiks! Šoreiz nav atuāli, bet radiovilnis vienā uS noskrien 300 metrus.

----------


## sasasa

> Bet kāpēc jābūt tādai precizitātēi?


 Finālā vēlams dabūt 10-20us precizitāti mērījumiem no 2-3 sensoriem. Ieskaitot sensora nostrādāšānas kļūdu + reakcijas ātrumu + laika nobīdi + vēl kādas kļūdas. Jo mazāka kļūda katrā posmā, jo mazāka kopējā kļūda.




> Iedomājies situāciju: Raidītājs sūta pliku ON/OFF (OOK modulācija vai FSK).


 Tagad tik jāizdomā kā nosūtīt pliku ON/OFF. Es pagaidām nevaru izdomāt.
Un vēl mani neliek mierā doma, kas notiks tad, ja sinhronizācijas signāls pienāks laikā, kad notiek mērījums? Ja tas nojauc mērījumu, tad ir ziepes. Vienīgais ko redzu ir atlikt tajā brīdī sinhronizāciju līdz nākošajam sinhr. signālam. Attiecīgi sinhr. signāli jāsūta pietiekoši bieži, lai izlaižot kļūda nepārsniedz pieļaujamo.

----------


## JDat

Ai. Kaut kas tev ir pārāk samudrīts, un kārtējo reizi negribi stāstīt savu slepeno biznesa plānu.

Shonizācijai pietiks ar tik tupiem moduļiem kā šie:
http://www.argus.lv/shop/productinfo/A016293
http://www.argus.lv/shop/productinfo/A016292

Manā uztverē, tas izskātās tā:
sensormodulis:
ESP8266 pieslēdzas kur vajag un sūta pa Wifi datus.
HM-R 868 MHz uztvērējs sinhronizācijai
Sensori kaut kādiem spēkiem pieslēgti pie ESP

Bāciņa: Arduino
HM-T 868MHz raidītājs sinhronizācijai.
Arduino rausta TX pinu teiksim ar kHz (precizēt iekš raidītāja datasheet).

Rūteris+Serveris Utt, kur dati tiek saņemti pa WiFi un saglabāti/apstrādāti.

Kamēr rakstīju jauna ideja: Kāpēc jāties? Paņemam ESP un ieliekam iekšā NTP klienta kodu + savu sensoru mērīšanu. 
Nevajadzēs neko lieku.

Tāda sajūta ka esi saputrojies ko īsti Tev vajag. Patiesībā, nevis saputrojies, bet stāsti pārāk mīklaini.

----------


## Jurkins

> Jurkin! Kā zināt cik uS pagājis no brīža kad tu pabeidz SPI sarunu ar raidītāju līdz brīdim kamēr uztvērējs norausta interrupt kāju? Tas ir laiks! Šoreiz nav atuāli, bet radiovilnis vienā uS noskrien 300 metrus.


 Bet abi uztvērējmoduļi interrupt kāju noraustīs ar to atšķirību, ko tas vilnis noskries līdz pirmajam un līdz otrajam. Vai svarīgi ir tas, cik tas signāls skries līdz kājai, pat līdz antenai. 

Es saprotu tā - divi sensori, katrs ar savu SI (vai MRF vai C1101..) modulīti. arduino vai ESP noraida sinhroimpulsu. Abi uztvērēji nonullē pulksteņus. Notiek slepenais notikums. Abi uztvērēji pārvēršas par raidītājiem un nosūta savu taimstampu uz "centru" (ne abi reizē). Centrs atskaita vienu taimstampu no otra.

----------


## JDat

> Bet abi uztvērējmoduļi interrupt kāju noraustīs ar to atšķirību, ko tas vilnis noskries līdz pirmajam un līdz otrajam.


 Tieši šis ir svarīgi. Jautājums: cik ātri (dažādi) nostrādās squelch un notiks pielokošanās katram uztvērējam.

----------


## karloslv

Nu paga, nevajag paļauties uz squelch. Normāli pakas saturs jau ir tāds - preambula (pietiekami gara, lai dažādās situācijās squelch nostrādātu), sinhrobiti, tad pakas saturs un varbūt postambula/CRC. Preambula un sinhrovārds jau ir _iebūvēts_ Silabā. Lokošanos pie preambulas un sinhrobitiem Silabs nodrošina pats cieti dzelziski, un tajā brīdī, kad sinhrobiti ir nokapčurēti, ir īstais brīdis sinhronizēties. Turklāt Silabs uz brīvas GPIO kājas var izlikt tieši šo synchroword nostrādāšanas indikatoru. Squelch nostrādās random brīžos un ar nevajadzīgi lielu izkliedi.

----------


## sasasa

> Ai. Kaut kas tev ir pārāk samudrīts, un kārtējo reizi negribi stāstīt savu slepeno biznesa plānu.


 Stāstu!
Ir 3 sensori. 2gb no tiem 100m attālumā un 1gb 50cm attālumā no bāzes savienots ar vadu (ja vajag var arī bez vada, līdzīgi kā attālinātie). Sensori (pjezo) nosūta saņemto signālu (pirmo fronti) uz bāzi.  Kopējais viena cikla (3 sensoru) signālu pienākšanas laiks 0.05 - 2s. Nākošais 3 signālu cikls sākas ne ātrāk kā pēc 10s. "Bāze" ir izvēlēta (nav akmenī kalts) ESP8266 (plusi - WiFi, 80MHz, pietiekoša atmiņa utt), kas saņem, saglabā un apstrādā datus un rezultātu (laika intervālus starp signāliem) parāda kā web serveris, lai varu redzēt planšetē vai telefonā turpat blakus (nevajag papildus displeju vai monitoru). No tās pašas planšetes arī vadība (5 pogas uz ekrāna) caur to pašu web lapu. Dati nekur uz ārpasauli nav jāsūta. Pat iekšējā tīklā viņi ir tikai dēļ displeja, jo esmu par slinku likt monitoru un lodēt podziņas. Varētu datus pārsūtīt arī caur to pasu WiFi un visur likt ESP8266, bet neērtības sagādā 100m attālums un nez kā tur ar pulksteņa/taimera sinhronizāciju tam ESP modulim? Varbūt tos 100m var pārvarēt uzliekot pa vidu kādu rūteri, tad tikai 50m paliktu uz katru pusi?
Šobrīd tiek meklēti piemēroti RF moduļi attālināto sensoru datu pārraidei uz bāzi un iespējas pārsūtīt signālu - vai nu ļoti ātri pēc sensora nostrādāšanas vai nesteidzoties, bet ar laika kodu.
Par cik ar laika kodu varētu iegūt stabilākus rezultātus, tad varianti kā sinhronizēt visu 3 sensoru pulksteņus.
Nu kaut kā tā. Ja kas nesaprotams vēl izstāstīšu.
p.s. Biznesa plāna nav, jo projekts bezpeļņas.

----------


## Jurkins

> Lokošanos pie preambulas un sinhrobitiem Silabs nodrošina pats cieti dzelziski, un tajā brīdī, kad sinhrobiti ir nokapčurēti, ir īstais brīdis sinhronizēties.


 Nu lūk,es jau par to pašu.

----------


## JDat

> vai nesteidzoties, bet ar laika kodu.


 Vo! Tas jau ir kaut kas. Jābūt precīzam laikam. Dati tiek nosītīti pēc 2 sekundēm. Mērīšanas intervāls 10 sekundes. Paņemam šo kā atskaites punktu.

Tātad ja pieņem ka visi radiouztvērēju moduļi nostrādā vienlaikus (lodējam, programmējam, skatamies rezultātus), tad pilnīgi pietiek ar tik primitīviem HM-T un HM-R moduļiem, bet... Tur ir vairāk mīnusu ne kā plusu. Kaut vai organizēt ar tiem pašiem moduļiem stabilu datu pārraidi. Labākajā gadījumā ser tikai sinhronizācijai un aizņem ēteru. Gribās kaut ko vairāk? Naksies iedziļināties SiLabs vai tml moduļos. Pie tam daudz dziļāk ne kā Jurkina gadījumā.

Sāc ar uztvērēju "vienlaicīguma mērīšanu" uz galda.

PS: Kur ir problēma ar ESP un 100 metriem? Vai pieliki normālāku antenu? Prasās ESP ar antenas konektoru. Ja nemaldos, tad Didzim ir kaut kādas WiFi antenas, kuras varētu pielāgot.

----------


## sasasa

> Kamēr rakstīju jauna ideja: Kāpēc jāties? Paņemam ESP un ieliekam iekšā NTP klienta kodu + savu sensoru mērīšanu. 
> Nevajadzēs neko lieku.


 Neatrodu info par to cik liela precizitāte ir ar NTP?
Ja lieku NTP klientu, tad kur ņemu sinhronizācijas signālus. Viss notiek tikai iekšēja tīklā, bez piekļuves ārējam (internetam), jo citādi man tur vēl GSM simkarte jāstelle klāt  :: 




> PS: Kur ir problēma ar ESP un 100 metriem? Vai pieliki normālāku antenu? Prasās ESP ar antenas konektoru. Ja nemaldos, tad Didzim ir kaut kādas WiFi antenas, kuras varētu pielāgot.


 
Nepieliku normālu antenu, jo sobrīd man ir tikai pliki ESP12e, bet vai ir cerība ar neliela izmēra antenu aizvikt tos 100m? Gabarītiem ir nozīme - sērkociņu kastītes izmērs būtu ideāls.
Laikam jau ka jāizmēģina, tik atkal tas gaidīšanas laiks kamēr no eBaja atnāks  ::

----------


## JDat

NTP serveris dod laiku. Tā ir tava bāze. Ja pareizi sapratu, tad nav svarīgi cik pulstens ir tavā bāzē. Vai ir 2016. gads vai 1970 gads. Ja gribās +/- pareizu laiku bāzei, tad pieskrūvē kāt RTC mikreni (DS1307). Tātad sensori no bāzes iegūst "pareizu" laiku. Tas arī viss, bet... klīst baumas (wikipedia) ka pa ethernet var iegūt +/- 100 uS precizitāti. Kā ir 21. gadsimtā? Kā ir ar ESP (gan dzelžu, gan softa ziņā)? Atkal laboratorijas darbs...

Ja nesanāk ar NTP (visdrīzāk ka nesanāks), tad pamēģini ar radio+WiFi. Negribas WiFi? Radio+Radio.

Ja būs brīvs laiks, tad pamēģināšu kaut ko uzrakstīt priekš MCU un patestēt ar vada palīdzību.

PS: Tiko atradu vēl vienu interesantu lasāmvielu: Precision Time Protocol Arī te var pasmelties idejas kā notiek pulksteņu sinhronizācija.

----------


## sasasa

Jā, to precizitāti ar NTP dažādi traktē. 
Man tā iespēja dabūt signālu pēc "Valid Preamble Detected" Si4430 modulim neliek īsti mieru, bēda tik tā ka man to moduļu šobrīd nav. Teorētiski liekas ka varētu būt labi.. Bet par cik mana pieredze nav nekāda šajā jomā, tad atliek vien zīlēt un gaidīt mēnesi vai pat vairāk, kamēr no eBaja atnāks
Protams ka man būtu ērtāk izmantot esp8266, bet tā precizitāte....   laikam paeksperimentēšu ar tiem un tad jau manīs. 
Ja vien atradīšu NTP servera kodu priekš ESP8266. Github tikai klienti vien  :: 
Tnx par idejām!  ::

----------


## JDat

Bet... Nav 100% jāatkārto NTP vai PTP. Jāsaprot pēc kādiem principiem strādā šie zvēri. Būtība ir tajā ka katram ir sav "pulkstenis" un tiek peēnmt ka signāls turp un atpakaļ ceļo vienādu laiku. Tur pat tiek sūtīts arī "servera" laiks un "klients" vienkārši piedzen savu pulksteni. Sākumā uztaisi ar vadu un diviem arduīniem. Tālāk aizksrien uz argusu un paņem kaut kādu moduļu pāri. Kamēr eksperimentēsi, tikmēr ebrejs atsūtīt gan papildsu ESP, gan Silabs gan visu pārējo.

Tāds laboriņš: Savienojam divus arduino kopā ar vienu pinu (un GND protams). Palaižam katrā arduino Timer2 ar frekvenci 1 vai 16 MHz (kā gribi).
Serveris random laikā (teiksim reizi sekundē) piefiksē Timer2 rādījumu un norausta pinu (prasās pēc ASM koda) un nosūta pa Serial uz datoru, lai Tu redzi.
Klients gaida kad noraustās PINs un piefiksē sava Timer2 rādījumu (prasās ASM) un nosūta pa Serial uz datoru, lai Tu redzi.
Savāc datus un izpēti kā mainās rādījumi. Nav svarīgi ko katrs timer rāda. Svarīgi kāda ir atšķirība starp diviem blakus esošiem mērījumiem. Būs nojausma kā tas viss strādā.

Pēc tam atkārto to pašu ar lētajiem radiomoduļiem.

----------


## next

Es negribu iedziljinaaties jo nesaprotu kas tiek dariits.
Bet tomeer jautaajums - kas liek domaat ka uztureet un sinhronizeet autonomus pulkstenjus vareetu buut vieglaak kaa vienkaarshi fikseet notikumus un  aatri un preciizi aizgaadaat info uz baazi?

----------


## JDat

K'a realizēt to tavu "ātri un precīzi aigādāt"?

----------


## next

> K'a realizēt to tavu "ātri un precīzi aigādāt"?


 A pulkstenjus sinhronizeet tak "leeni un nepreciizi" arii nevarees.
Nu tad leeni un preciizi buus jaadara.
Un kaa to dara?

P.S. Es jau sapratu ka neko nesaprotu, buushu pateiciigs ja kaads paskaidros, nopietni.

----------


## Obsis

Vispār vai zinājāt, ka Latvijā ražo pasaulē ātrākos pulksteņus - Elektronikas Institūta meitas firmā, Event-Timer, kas sinhronizē divus pulksteņa laikus ar ja nejaucu 4 atosekunžu precizitāti. Piko--> femto-->ato.... Nu dabistiski, ka tas verķis maksā orientējoši sešciparu skaitli.
Parastiem pielietojumiem mums te ir nācies salīdzināt Cēzija atomstandarta pulksteni ar GPS rādījumiem. Cita starpā pārsteidzoši, bet PARASTS GPS ir par apmēram 2-3 kārtām sliktāks nekā Cēzijs, bet specializētais gps par nedaudz simtiem naudiņām gabalā atšķīrās par nepilnu kārtu.
Turklāt Cēzija pulkstenis bija ar ļoti zemu fluktuāciju, bet sliktu ilgtermiņa stabilitāti, savukārt gps bija ar ideālu ilgtermiņa stabilitāti bet samērā fluktuatīvs. Lai vai kā, ar kārtīgu matemātisko apstrādi var cerēt pietuvoties maģiskajai 20.ajai zīmei aiz komata, bet sasniegt 18~to nav problēmu. Ja tas apmierinā, tad jāņem visprastākais gps resīveris pa piečuku gabalā, jāizvelk vads, kas dod NMEA koda sekvences un tur pēc tabulas sakrāmēsi kas ir kas par signālu. Vismaz salīdzinājumā ar radioraidītāju, kas visideālākajā gadījumā sasinhronizēs mikrosekunžu simtus, šis sasinhronizēs pikosekunžu simtus. Trīs raidītājus nav iespējams iebarot vienlaicīgi, ja ar vārdu raidītājs saprotam digitālos kodus saprotošus verķus. Un arī vecos labos analogos raidīkļus telpa pati par sevi izčakarēs, kā nekā 30 metri distance atbilst 0,1 mikrosekundi nobīdei. Tas ir mežonīgi neprecīzi!! Kabeļu garums, ja izlemsi atteikties no radioviļņiem nebūt nav daudz labāki, aizkave tā pati, tik vien ka vari visus vadus paņemt vienādi garus.
Vēl viena metode ir optiskais kābelis. Jo HFBR un tam līdzīgie verķi principā tiek līdz nanosekundēm un pat virs. Vismaz sinhropakete iegūs traucējumnoturību.
Deviņpadsmit suņus un trīs mucas sāls laika sinhronizācijas jomā ir izēdis mūsu 5.stāvā tāds Alnis. Soļo šurp un varbūt risinājumu var piemeklēt.

----------


## sasasa

> A pulkstenjus sinhronizeet tak "leeni un nepreciizi" arii nevarees.
> i.


 Jā, next taisnība. Nav starpība vai sinhronizēt pulksteņus un tad sūtīt laiku, vai sūtīt uzreiz signālu. Kļūdas lielums ta būs vienāds, ja izmanto to pašu raidītāju/uztvērēju.




> ... Ja tas apmierinā, tad jāņem visprastākais gps resīveris pa piečuku gabalā, jāizvelk vads, kas dod NMEA koda sekvences un tur pēc tabulas sakrāmēsi kas ir kas par signālu. Vismaz salīdzinājumā ar radioraidītāju, kas visideālākajā gadījumā sasinhronizēs mikrosekunžu simtus, šis sasinhronizēs pikosekunžu simtus. Trīs raidītājus nav iespējams iebarot vienlaicīgi, ja ar vārdu raidītājs saprotam digitālos kodus saprotošus verķus. Un arī vecos labos analogos raidīkļus telpa pati par sevi izčakarēs, kā nekā 30 metri distance atbilst 0,1 mikrosekundi nobīdei. Tas ir mežonīgi neprecīzi!! Kabeļu garums, ja izlemsi atteikties no radioviļņiem nebūt nav daudz labāki, aizkave tā pati, tik vien ka vari visus vadus paņemt vienādi garus..


 Obsi, ir tāda nianse, ka man NEVAJAG, lai tie visi sensora raidītāji būtu precīzi vienādi laikā, bet gan lai viņu savstarpēja nobīde no nosacīta 00:00 punkta būtu nemainīga. Kāds sensors var sūtī savu signālu kaut vai sekundi vēlāk, ja vien šīs sekundes intervāls tiek ieturēts no reizes uz reizi.  Līdz ar to nav svarīgi cik ilgi skrien radiovilnis līdz viņiem, jo katru reizi viņš skries ar vienādu ātrumu. Analizējot saņemtos datus tiek salīdzināts nevis absolūtais laiks starp saņemtajiem impulsiem, bet gan relatīvi cik tas savstarpējais impulsu laiks mainās no viena mērījumu cikla uz otru. Līdz ar to man ir svarīgi, lai pulksteņi/taimeri laiku pa laikam tiek sinhronizēti pēc viena un tā paša signāla tikai tāpēc, ka visi taimeri nedarbojas ar pilnīgi identisku frekvenci un nevis tāpēc ka tie rāda atšķirīgu laiku.
Kaut kā sarežģīti sanāca, bet ceru ka sapratīsiet.

----------


## Elfs

Tad jau nav starpības principā vai laiku pa laikam sinhronizē vai vienreiz nokalibrē- tobish nomēra katru kanālu atsevishķi un tad lai tā bāzes stacija visu rēķina

----------


## sasasa

> ...vai vienreiz nokalibrē- tobish nomēra katru kanālu atsevishķi un tad lai tā bāzes stacija visu rēķina


 Vienreiz nokalibrēt neizdosies, jo katrs konkrētais taimeris nebūs nemainīgs visu laiku, pat precīzs RTC. Frekvence jebkurā gadījumā peldēs un rezultāta precizitāte jau pēc stundas būs galīgi greiza, nemaz nerunājot par to kas būs dienas beigās. Var protams izmantot precīzu RTC un tad retāk sinhronizēt, piem. ik pa 10 min (to bez rēķināšanas nosaucu), bet pa lielam nav starpības vai ik pa 10 min vai ik pa 10s sinhronizēt.

----------


## Jurkins

Eu, veči, nu autoram tak nevajag pikosekundes!!! Kādus cēzijus!  ::  Noprogrammē raidītājam preambulas (0,1,0,1,0,1,0,1...) garumu (līdz 255 baitiem) un uztvērējam "preambulas slieksni" - cik biti no preambulas ir jāsaņem pareizi, lai uzskatītu, ka viss ir ok. Šeit varētu slēpties problēma. Ja uztvērēji ir dažādos uztveršanas apstākļos, tad šie sliekšņi varētu tikt sasniegti ne vienā un tanī pašā brīdī. Tāpēc neizmantojam  "valid preamble" signālu. Dodam tālāk "sinhrobaitus" (1..4) un piem. vienu, divus, trīs... baitus informācijas(jebkādu). Uztvērēji izrēķinās CRC un, ja viss būs ok, mēs dabūsim pārtraukumu "valid packet recieved". Tas viss notiek hārdvārē. Ja uztvērēju modulīši ir vienādi, tad arī šis notikums notiks ar savstarpējo nobīdi par 0.1us uz 30 metriem. Nu jā, kaut kādas kvarcu nestabilitātes... bet vai tas būs būtiski autora vajadzībai? var jau būt, ka no nrf arī var izdabūt ārā kaut kādu šādu pārtraukumu. 
Var jau būt, ka risinājums "čerez žopu", bet nekomerciālam projektam tak neies kolaideru būvēt.

edit: nrf arī ir pārtraukums "valid packet recieved".

----------


## Jurkins

Nja, nu tas nrf ir advansēts, velns viņu zin, kas šim iekšā notiek. Nez, kas peld. Raidītāja gals vai uztvērēja gals.

----------


## sasasa

Sorry kļūdījos, kaut ko ne tā biju saspraudis. reāli tagad  laiks no pogas nospiešanas līdz IRQ signālam peld 20us robežās. Neteikšu ka baigi labi, bet reāli jau pamazām pietuvojas pieļaujamās kļūdas robežai

812
820
812
816
812
808
816
816
828
808
812
812
812
820
808

Pilna datu paka atnāk stipri mainīga laikā - peld ap 40us
1040
1052
1044
1020
1048
1016

tur vēl kautkādi delay tai RF24 bibliotekē bija. Vēl pačekošu - varbūt ko var noņemt
tas ka tur veselas 800us priekšā mani galīgi nesatrauc. var gan arī tās samazināt, ja neļauj gulēt un nav jāmodina. Paskatīšos cik tas izmaina saņemšanas laika peldēšanu

----------


## Jurkins

Gan jau tam nrf vajag atslēgt visādus ACK un protokola navarotus, ja tādi ir.

----------


## sasasa

Samazinot PayloadSize  kopējais laiks vēl samazinās līdz 432-452us (pie 2MBPS), bet peldēšana tāpat paliek 20us. Vienīgais ka lasīju, ar šo varot palielināt attālumu. Bet tad pilnai laimei jāsamazina arī datu pārraides ātrums uz 250kbps, kas rezultātā palielina kopējo laiku līdz 1816-1836us. Pagaidām nevaru atkost kas tieši izraisa šo 20us peldēšanu. Vidēji tā ir tikai 12us, bet ik pa brīdim aiziet līdz 20  :: 
Tomēr šī "laboratorijas darba" rezultāts nav zemē metams. Ceru ka neesmu atkal sajaucis kādus vadus   :: 
Kaut kāda kļūda varētu būt dēļ tā, ka mēru uz tā paša Arduina, kurš darbojas kā uztvērējs, bet pagaidām negribas spraust klāt vēl trešo, jo rezultāts ir jau praktiski reālai starta pozīcijai.

----------


## JDat

cik saprotu, tad nav svarīgi vai dati atnāk pēc 20 uS vai pēc 1000 uS. Svarīga ir stabilitāte. Lai vienmēr būtu stipri līdzīgi cipari. nRF izmēģināji. Izmēģini argusa sūdmoduļus. Tad arī domāsi tālāk.

----------


## Jurkins

A tam nrf nevar tāpat kā SI "ar roku" morādīt, cik gara preambula, cik garš tas slieksnis uztvērējam u.t.t?

----------


## sasasa

Pagaidām, cik sapratu, var mainīt :
setCRCLength();//8,16,32
setPayloadSize();//1-32
ko kurs nozīmē vēl neesmu izpētījis
un tad vēl
setAutoAck(true);
enableAckPayload();
enableDynamicPayloads();
disableCRC (void)
ko visi šie nozīmē arī īsti vēl nesaprotu
http://maniacbug.github.io/RF24/classRF24.html

----------


## sasasa

Laikam šobrīd atmetīšu domu par taimeru sinhronizāciju un atgriežos pie iepriekšējā topika par signāla parraidi. Neredzu nekādu ieguvumu no taimeru sinhronizācijas, jo summārā kļūda teorētiski paliek tāda pati. Savukārt pārraidīt sensora signālus un salīdzināt to pienākšanas laikus "bāzē" man šķiet ērtāk.
Ja nu kādas jaunas idejas, tad esmu gatavs uzklausīt  ::

----------


## sasasa

Laikam par agru atmetu šo domu. Ienāca galvā dažas idejas (tik kāpēc vienmēr naktī?), ar software algoritma palīdzību uzlabot precizitāti. 
Šobrīd liekas kārtējā dullā ideja, bet teorētiski varētu sasniegt pat <1us precizitāti pat ar raidītāja 20us kļūdu.
Ja kaut kas izdosies, tad gan jau ka palielīšos šeit  :: 
..ja ne aiziešu alu nopirkt..

----------


## sasasa

Kaut ka jau nu baigi optimistiski izskatās tas kļūdas samazināšanas algoritms. Tikko uzmodelēju matemātiski iespējamo kļūdu, ja signāla neprecizitāte ir 40us (+-20). Rezultātā jau pēc 2 sekundēm (solis pa 0.1s) mans greizais sinhro signāls jau iekļaujas 1us robežās. Tālāk praktiski tikai tik cik peld frekvence + pārtraukuma nostrādāšanas laika neprecizitāte, kas neiekļaujas korekcijas rāmjos. Pēc šāda principa izskatās, ka varu bezmaz vai bez problēmām sinhronizēt arī caur WiFi, ja vien tur signāla laiks nepeld vairāk par 200us.
Šī bilde ar fluktuāciju 40us. Rezultāts vienkārsi ideāls

šī ar fluktuāciju 200us - rezultāts  <5us



Tiesa tie ir tikai matemātiski aprēķini. Kā būs realitātē, to laiks rādīs. Jāpapēta vēl kādus algoritmus izmanto NTP un GPS. Varbūt var ko nošpikot.

----------


## JDat

> Jāpapēta vēl kādus algoritmus izmanto NTP un GPS. Varbūt var ko nošpikot.


 Nu tad beidzot! Papēti gan. Ir pietiekoši interesanti. Redzēsi ka kļūda salasīsies tieši ur laiku kamēr paketes ceļo caur WiFi un gaisu. Ja tur ir kostantas latences, tad ar pārējo tiksi galā.

----------


## sasasa

> Redzēsi ka kļūda salasīsies tieši ur laiku kamēr paketes ceļo caur WiFi un gaisu..


 Par WiFi laikam tomēr neesmu īsti priecīgs. Nomēriju Ping no mobilā uz ESP8266. Tur 8.21-26.2ms.  ::   Gandrīz 1000x vairāk kā nRF24. Vai tiešām WiFi ir tāds bremze?
Neesmu speciālists ICMP(Ping), UDP un NTP, bet liekas vai tik Pingam nav pati mazākā pakete un īsākais laiks.

----------


## JDat

Jā ir viena no vienkāršākajām paketēm. Timēr, te bez WiFi radio traksta intensīvi iestaistās arī procesori un tas jau ir pavisam cits stāsts. Drīzāk atbildi uz jautājumu: kapēc NTP strādā caur WiFi. Varbūt tavām prasībām nebūs piemērots, bet tomēr.

----------


## sasasa

> Drīzāk atbildi uz jautājumu: kapēc NTP strādā caur WiFi. Varbūt tavām prasībām nebūs piemērots, bet tomēr.


 Strādā tapēc ka piemērots protokols. Atradu te aprakstiņu no Texas Instruments, ka rāda, ka tomēr ir iespējams caur WiFi arī 5us dabūt, bet liekas, ka tur visa fīča ir dzelzī.
http://www.ti.com/lit/an/swaa162a/swaa162a.pdf

----------


## JDat

> Strādā tapēc ka piemērots protokols.


 Daudz kas ir piemērots daudzām lietam un vienlaikus vienmēr kaut kas ir jāpielāgo.




> Atradu te aprakstiņu no Texas Instruments, ka rāda, ka tomēr ir iespējams caur WiFi arī 5us dabūt, bet liekas, ka tur visa fīča ir dzelzī.
> http://www.ti.com/lit/an/swaa162a/swaa162a.pdf
> 
>  7350


 Interesants dokuments, bet izksatās ka katrā nodē (gan bāze, gan sensors) vajadzēs maziņu linux...

Ja atrod superrraidītāja un superuztvērēja komplektu, kurš vienmēr nosūta datus ar constantu latenci (nav svarīgi cik gara, zvarīgi lai vienmēr it konstanta, vienalga vai 20 uS, vai 1000 uS, bet konstanta.
Tad katrs sensors dara sekojošu lietu: Palaiž timer, ar maksimālo rezolūciju. 1 MHz, 16 MHz 20 MHz (kā patīk) un precīzi pēc 1 sekundes (0.1 sec utt, kad patīk). Sūta savu pulksteņa rādījumu uz bāzi.
Ja pēkšņi notrigerējas piezosensors, tad arī nosūta sava pulksteņa rādījumu uz bāzi.

Skaidrs ka divi sensori nevar vienlaikus raidīt, bet tas ir atsevišks stāsts.

Bāze: Saņem paketi un, pirmkārt, piefiksē cikos pēc bāzes pulksteņa pakete atnāca. Tālāk notiek paketes datu apstrāde, kuras rezultātā, bāze zin cik cik pulkstenis ir sensorā. Pārrēkina lai zin cikos sensors sūta pēc bāzes pulksteņa laika. Tas arī viss.

Visa būtība slēpjas ka sūta paketes precīzi pēc sekundes un ir konstanta latence. Pirmo Tu vari nodrošinās uz arduino, otro... Tas jau ir grūtāk.
Viss strādā ļoti labi līdz brīdim kamēr var garantēt konstantu datu kanāla (raidomoduļu) latenci. Pietiktu pat ar vienvirziena sakariem.

Par cik internetā (gan NTP, gan PTP) gadījumā nevar garanatēt konstantu latenci, tad ši latence tiek mērīta sūtot savu pulksteņa rādījum un saņemot otra gala (bāzes) pulksteņa rādījumu un tad izrēķina gan latenci, gan arī pulksteņu laika stapību. Iekš wiki ir divas elementāras formulas ar saskaitīšanu, atņemšanu un dalīšanu ar 2 (ātrdarbībai var izmantot >>1, jeb right shift priekš dalīšanas).

Un vēl. Kad eksperimentē ar kodu, tad vai vairākus arduino saslēgt kopā caur software Serial kas kāreiz ienes visādas dīvainības utml kokus. Ja šādā sistēmā dabūsi labu sinhronizāciju, tad princibs būs skaidrs un atliks tikai pieskrūvēt klāt radiolietas, bet tas jau ir cits stāsts.

----------


## JDat

Atverējos vēl vienu lietu: Vecais labais DCF77. Googlējam ja nezinam.

Interesants raksts, kurš izkaudro kā 10 mS vietā tika iegūta dažu uS precizitāte. 
https://www.meinbergglobal.com/english/faq/faq_23.htm

Tātad var apsvērt iespēju izmantot PRN ciparus un kodā simulētu PLL, bet te vajag vēl vienu pētījumu un dziļāku sapratni par tēmu.

'Tālāk attīstot domu par PRN un PLL sinhronizāciju, lēnām tiek izgudrots savs privātais GPS. ne gluži naFigācija, bet var aizrakties līdz tam pašam principam, kuru izmanto GPS pulksteņu sinhronizācijai. Sasasa Gadījumā bāze pilda GPS satelīta funkciju, kurš piegādā pareizu laiku, savukārt sensori ir GPS uztvērēji, kuru pulksteņi tiek piesinhronizēti bāzei. Ņemot vērā attālumus uc faktorus, tas ir realizējams. Paliek tikai jautājums: WTF? KĀ to izdarīt?

----------


## sasasa

> Tad katrs sensors dara sekojošu lietu: Palaiž timer, ar maksimālo rezolūciju. 1 MHz, 16 MHz 20 MHz (kā patīk) un precīzi pēc 1 sekundes (0.1 sec utt, kad patīk). Sūta savu pulksteņa rādījumu uz bāzi.


 Interesanta ideja. Principā tas pats jau vien ir tikai apgriezts otrādi. Ieguvums ir tāds, ka sensora modulim nav jāveic nekādas kalkulācijas, sinhronizācijas un aprēķini. Tikai nedomājot jāsūta impulsus. Tiesa tur varbūt vajadzēs (varbūt arī nevajadzēs) precīzāku impulsu ģeneratoru, jo esošais uz Arduino vai ESP8266 varētu diezgan stipri peldēt, bet nav problēma vismaz RTC moduli pielodēt. 




> Ja atrod superrraidītāja un superuztvērēja komplektu, kurš vienmēr nosūta datus ar constantu latenci (nav svarīgi cik gara, zvarīgi lai vienmēr it konstanta, vienalga vai 20 uS, vai 1000 uS, bet konstanta...
> ...Visa būtība slēpjas ka sūta paketes precīzi pēc sekundes un ir konstanta latence. ...
> ...Viss strādā ļoti labi līdz brīdim kamēr var garantēt konstantu datu kanāla (raidomoduļu) latenci.


 Nav tik traki. Matemātiski/programmātiski es to varu samazināt vairākus desmitus reižu.

--
Radās atkal jaunas idejas par WiFi, un iespējams ka arī ar ESP8266 varetu to visu izdarīt, ja vien pārprogrammētu WIFi datu saņemšanas/apstrādes algoritmu. Tā milzīgā Ping aiztures izkliede esot tikai dēļ nepareiza koda, vismaz tā man apstāstīja. Šobrīd pamatīgs traucēklis ir manas vājās zināšanas programmēšanā un pilnīga C++ nezināšana  ::

----------


## JDat

Impulsu ģeneratoru peldēšana ir problēma. To varētu risināt ar sarežģitāku sistēmu. Tieši tur parādās NTP algoritms un divvirzienu sakari. Tātad... Kā strādā NTP?
Sensors nosūta bāzei pierasījumu: "Hei, bāze! Cik laiks pēc Grinvičas? Mans pulstenis rāda tik un tik.
Bāze piefiksē cikos atnāca pakete un atbild: "Tavu paketi saņēmu plkst tikos un tikos pēc Grinvičas. Mans pulkstenis rāda tik un tik"
Sensors saņem atbildi un piefiksē cikos pēc lokālā laika atnāca pakete.
apzīmējumi:
t0= brīdis, kad sensors izsūta pieprasījumu bāzei
t1= brīdis, kad bāze saņem pieprasījumu
t2= brīdis, kad bāze sāk sūtīt nosūta paketi
t3= brīdis, kad sensors saņem atbildi

Tālāk matemātika.
Starpība starp lokālo laiku un bāzi (NTP to sauc pa theta Θ): Θ=( (t1-t0)+(t2-t3) ) / 2
Latence caur radiokanālu (NTP to sauc par delta δ): δ=(t3-t0)-(t2-t1)

Tālāk sensors atrod brīdi, kurā pieskaitīt klāt thera pie sava pulksteņa un viss.

Problēmas: Latence visu laiku mainās. LINUX utml sistēmas tik vienkārši nedara. Tur visu laiku tiek prasīti vairāki NTP serveri. Tiek katram rēķināta latence un "ticamība", jo arī NTP serveri var sajukt prāta. Rezultātā tiek veikti noapaļojumi un "trokšān" (laika mērījumu straigāšana) un tikai tad tiek veiktas korekcijas lokālajā pulkstenī. Un tā visu laiku kamēr linux mašīna ir ieslēgta.
Tavā gadījumā arī vajadzētu sensoram vajadzētu uzkrāt vairākus mērījumus un rēķināt vidējo + atmest datus, kuri ir "pārāk atšķirīgi" no normāliem "datiem".
Piemērs: palaižam bāzi. Bāze strādā un rāda uz Tava 16x2 Displeja kaut ko.
Palaižam sensoru. Sensors pilnīgi neko nezin par pareizu laiku. Sāk prasīt bāzei laiku. Bāze atbild. Pēc teiksim 20 aptaujām sāk parādīties vidējais laiks un sensors piesinhronizējas.
Uzksrūvē šo ideju uz arduino un pa vadiem patestē.
Kad atnāks ESP moduļi, tad:
a) ieskrūvē to pašu ESP moduļos un paskaties cik viss ir labi/slikti
b) Pārvērt ESP par kaut ko līdzīgu Serial to WiFi un izmanto katrā iekārtā kopā ar arduino.

Vārdu sakot: tev ir vēl ļoti daudz ko darīt, pat ja nav atnākuši visādi ESP, silabi, arduino utml gadgeti.

Es arī nemāku ne C, ne C++, bet lēnītēm rakstu to ko man vajag. Google vienmēr palīdz, ja māk noformulēt jautājumu.

----------


## sasasa

> Tavā gadījumā arī vajadzētu sensoram vajadzētu uzkrāt vairākus mērījumus un rēķināt vidējo + atmest datus, kuri ir "pārāk atšķirīgi" no normāliem "datiem".


 NU BET LOĢISKI  :: 
Es laikam pārāk maz zinu pat visām šī laika sinhronizēšanas sistēmām, bet varbūt arī tas ir labāk.  ::  Mans funktieris ir gaužām vienkāršs, bet liekas ka nekas vairāk šobrīd ari nav vajadzīgs.
Īsumā mans (kopā ar tavu ideju) algoritms, neiedziļinoties matemātiskajās niansēs, ir šāds:
1. Sensora bloki močī visu laiku impulsu 1Hz (varbūt no iebūvēta taimera varbūt no ārēja RTC - skatīšos pēc iegūtā rezultāta)
2. Bāze VISUS signālus krāmē 2 čupās (masīvos) piefiksējot bāzes laiku.
3. Bāze salīdzina pienākušo impulsu nobīdi no precīza 1Hz, nobīdes lielākas par _max_nobiide_ dzēš, akceptētās nobīdes summē un rēķina vidējo aritmētisko.
4. Pēc pienākušo impulsu laikiem + izskaitļotās korekcijas, tiek izskaitļotas sensora bloku 1Hz ģeneratoru darbība ar nepieciešamo precizitāti  (pie nosacījuma ka pienākošās paketes fluktuācija ir <200us), Precizitāte pieaug ar katru saņemto sinhronizācijas impulsu un beigās ir atkarīga tikai no signāla ģeneratoru nestabilitātes.
5. Bāze, zinot abu sensora bloku 1Hz ģeneratoru darbību, izskaitļo pjezosensora signālu laikus un intervālu starp tiem
Pjezosensora nostrādāšanas laiki tiek fiksēti pēc sensoru bloka laika un nosūtīti laikā starp sinhroimpulsiem.

Ja nu gadījumā ESP8266 tomēr nedarbosies ar pietiekošu stabilitāti, tad būs vien jāizmanto Arduino + nRF24.

Otrais variants (pareizāk sakot 1.) ir viss tas pats, tikai sinhronizācija tiek sūtīta no bāzes uz sensora blokiem, tur koriģēts laiks un atpakaļ saņemts sensora nostrādāšanas laiks jau ar pareizu _timecode_ abiem sensora signāliem. Mazāka noslodze bāzei, lielāka sensora blokam. Izmantojot Arduino+nRF nekadas atšķirības. Izmantojot ESP8266 varētu būt problēmas ar aizturēm, dēļ procesora noslogojuma

Vai esmu ko palaidis garām neievērotu?

----------


## JDat

> Otrais variants (pareizāk sakot 1.) ir viss tas pats, tikai sinhronizācija tiek sūtīta no bāzes uz sensora blokiem, tur koriģēts laiks un atpakaļ saņemts sensora nostrādāšanas laiks jau ar pareizu _timecode_ abiem sensora signāliem. Mazāka noslodze bāzei, lielāka sensora blokam. Izmantojot Arduino+nRF nekadas atšķirības. Izmantojot ESP8266 varētu būt problēmas ar aizturēm, dēļ procesora noslogojuma
> 
> Vai esmu ko palaidis garām neievērotu?


 Pagaidām nē, bet var būt kaut kur ir nianses.

Šajā kontektša NTP serveris un clients, nav tas pats kas IP NTP, bet gan vienkāršota versija, kuras darbības princips ir līdzīgs.
Kopumā pareizi. Uztaisam bāzi, kurā ir 2 NTP klienti (katrs savam sensoram).

Katrā sensorā ir savs NTP serveris.
Bāze prasa sensoriem teiksim 1x sekundē info un sensori atbild.
Atbilde satur jau iepriekš aprakstīto info par t0-t3 klāt pieliekot piezo nostrādes laikus.
Sensori atbild tikai tad, kad bāze viņiem kaut ko paprasa.

Šobrīd mēģinu uzrakstīt testa kodu uz MCU un izskatās ka serveris ir vienkāršāks par klientu (pagaidām).

Ja nepietiek ar ESP jaudu, tad klāt pieliec Arduino un ESP izmanto tikai kā sakonfigurētu UART to WiFi radiomoduli. Ja nesanāk par esošajiem ESP kodu paraugiem UART gadījumā, tad pats uzraksti tādu kādu Tev vajag.

Kas attiecas uz 2. (pirmo, augšā) variantu, tad neceri ka RTC frekvenci ir ļooti stabila. Tur prasās izmantot TCXO ģeneratoru. Vai nu pa taisno pie arduino, vai priekš atsevišķa ģeneratora. Viss atkarīgs no rocības un lodēšanas.

----------


## sasasa

> Bāze prasa sensoriem teiksim 1x sekundē info un sensori atbild.


 Kāpēc bāzei jāprasa? Sensora bloks bez prasīšanas sūta 1Hz. Un timecode sinhrosignālā ir tikai dēļ tā lai izskaitļotu pjezo nostrādāšanu, nevis lai laiku sinhronizētu.




> Ja nepietiek ar ESP jaudu, tad klāt pieliec Arduino un ESP izmanto tikai kā sakonfigurētu UART to WiFi radiomoduli.


 ESP = 80-160MHz  tā ka ar jaudu tur domāju pietiek. Vairāk uztraucos par tam aizturēm, kuras pagaidām neizdodas nostabilizēt, bet cerība ir.




> neceri ka RTC frekvenci ir ļooti stabila. Tur prasās izmantot TCXO ģeneratoru.


 Kas ir TCXO?  
Es domāju sākt ar ESP8266 čipā esoša ģeneratora frekvenci. Ja ne tad mēģināt papildus RTC, šobrīd man ir DS3231. Ja FINĀLĀ man gatavais rezultāts ieskaitot visas kļūdas būs <25us robežās, tad var teikt ka pirmajai "ieskaitei" viss OK.  :: 

.
Nianse būs vienmēr un tās atklāsiet tikai, kad reāli visu salikšu. ESPkas jau ir mājās kāda čupiņa, tiesa gan ar PCB antenām, bet experimentiem pietiks.

----------


## JDat

A) variants:
Problēma: Regulārajai sūtīšanai nav iespējams izrēķināt latenci. Ja latence no sensora1 uz bāzi ir vienāda ar latencl no sensora 2 uz bāzi, tad viss ir OK, bet dzīvē tā nebūs.

B) variants:
Sensors sūta atbildi, jo viss kas tur jāizdara:
1) pieraktīt piezo nostrādāšanu
2) Saņemt pieprasījuma paketi
3) ielikt iekšā t1,t2 un sensora nostrādāšanu
4) aizsūta atpakaļ apstrādātu paketi.

1. interrupt saglabā piezo nostrādāšanas laiku
2. interrupt piefiksē t1 laiku


Bāze prasa no sensora laiku+piezo datus. Tur ir 2 virtuāli NTP klienti + skaitļošana.
1. interrupt saglabā atbildes laiku

1) Sagatavo paketi
2)nosūta pieprasījumu
3) sagaida atbildi. Atcerās t3.
4) Izskaitļo laika nobīdi + noapaļošanas masīvi.
5) koriģē virtuālo pulksteni
6) apstrādā piezo datus.

7-12) Un tagad to visu pareizini ar divi.

TXCO: https://en.wikipedia.org/wiki/Crysta..._abbreviations
Kvarci, kuri ir kompensēti uz temperatūras mainīšanos. Precīzāki par paratajiem kvarciem.

Ja atrodi TCXO uz 32 kHz, tad izmanto priekš RTC. Ja atrodi TCXO ar ESP vai arduino frekvenci, tad RTC nav vajadzīgs.

----------


## sasasa

Tikko apskatījos - manam DS3231 modulim kā reizi ir TCXO  :: 

B... laikam galva vairs nestrādā -  jā, biju palaidis garām, ka ar vienpusēju signālu nevaru aprēķināt savstarpējo sensoru bloku 1Hz sinālu laika nobīdi.
Bet pieļauju, ka to turp/atpakaļ kontroles signālu var nesūtīt katru sekundi, bet retāk (piem 0.1Hz). Tas atslogotu ESP sensora blokā un varētu (varbūt) saīsināt aiztures laikus.
Jāsāk kaut ko raxtīt un experimentēt, tik sabiedēja mani ka es ar Arduino IDE (citu nemāku) neko jēdzīgu neuzrakstīšu. Pie kam ESP razotaji nepublisko WIfI kodus un darbības algoritmus, līdz ar to tikai ar mēģinājumu un kļūdu metodi nākas darboties  ::

----------


## JDat

Pieņem ka ESP WiFi ir melnā kastīte ar nezināmu latenci. Tieši tāpat kā jebkuš cits radiomodulis.

Viss ko Tev vajag:
uztaisi visus NTP utml pa vadiem uz galda. Tā lai tev viss strādā un sinhronizējas.
Tālāk uztaisi bāzi kā accesspoint (SSID, MAC IP adreses utt) un UDP klientu.
Kad UDP paka tiek saņemta, tad tavs kods apstrādā paciņu no masīva.

Sensoriem uzraksti WiFi klientu (SSID, password, MAc IP utt) un UDP serveri.
Senori apstrādā un sagatavo jaunu UDP paketi kā datu masīvu.

----------


## sasasa

> Pieņem ka ESP WiFi ir melnā kastīte ar nezināmu latenci. Tieši tāpat kā jebkuš cits radiomodulis.


 Šobrīd, ar to kā viņa man strādā, ESP8266 ir sū.. kastīte  ::   Kaut vai salīdzinājumā ar nRF24

----------


## JDat

Kompensē ar softa palīdzību. Pliks PING derīgs tika galvā tērētiem CounterStrik-istiem.

----------


## sasasa

Tu varbūt neieveroji, ka tur mērījumi nav us, bet gan ms. Ko es varu kompensēt ja kļūda ir 500x(!) lielāka par vēlamo rezultātu? Ok, saprotu, ka Pings vēl nav nekāds rādītājs, bet nu ja vismaz ja tas būtu 0.5ms robežās (tā arī būtu jābūt). Mana sūtītā pakete taču arī būs tāda pati, pat vēl garāka. Un kāpēc lai manis sūtīto paketi ātrāk saņemtu/nosūtītu.

----------


## JDat

Pirms cepies par ping skaitlīšiem:
a) cik precīzi ir tie skaitlīši?
b) apskati ping utilītas izejas kodu internetos
c) kā lielajiem onkuļiem sanāk tikt galā ar NTP, ja arī vieņiem ping tik ļoti lēkā?

Bonus Track) Uztaisi visu ar 3 arduino un vadiņiem. Vai arī ar 3 ESP un vadiņiem. Pagaidām WiFi nejauc iekšā. Tas būs pēc tam. Tev vajag strādājošu algoritmu un mērinstrumentu pims ķerkt ka ar WiFi viss kārtībā. Problēma ir domāšanas trūkumā, nevis zināšanu trūkumā.

----------


## JDat

Zini kā patiesībā ir: Abi esam lohi.

Viss jau sen ir izgudrots.
Nav ko čakarēties. Vienkārši jāpaņem DecaWave DWM1000 vai tml moduli. http://www.decawave.com/products/dwm1000-module
Čalis jau visu priekš arduino paspēja uzrakstīt. https://github.com/thotro/arduino-dw1000

----------


## sasasa

Modulītis interesants. Kādu laiku atpakaļ gribēju tādus izmantot sava robota vadībā, lai noteiktu atrašanās vietu telpā  ::  Tu domā viņu izmantot raidītāja/uztvērēja vietā vai tikai kā sinhronizācijas moduli? Būs jāpapēta sīkāk, bet dēļ dārgās sūtīšanas diez vai man pa kabatai.
 20$/gb  +  sūtīšana 49.54$, tas būs 90$ par 3gab   :: 
http://www.semiconductorstore.com/ca...0013#Documents 
Citur viņu neatradu.
-
Te kāds apraksts, pēc kura, cik es sapratu, WiFi iekārtas jau pašas sevi sinhronizē. Izskatās, ka pat dzelža līmenī. Visu gan nesapratu no tā raxta.
https://en.wikipedia.org/wiki/Timing...ation_Function

----------


## JDat

Nu tak piezvani uz Baltelectron un tur paprasi.

Jā Decawave moduļus jau pieminēju, kad gribēji robotu būvēt.
Jā, DecaWave moduļi māk nomērīt attālumu, jo izmanto laika sinhronizāciju. Skaties github piemērus.
Jā, DecaWave māk arī sūtīt un saņemt datus. Nav gluži Serial bibliotēka, bet tik un tā var iemācīties.

Itkā gudrs čalis, bet ar vārdiem: "Modulītis interesants" Saprotu, ka izlasīji reklāmas bukletu, uzgooglēji nezin ko par cenu+piegādi un atmeti ar roku. Nemaz neākot pētīt "kas, ko, kur, kā, kapēc, cik" Nezināšana par "cik" piedodama.

Daži tomēr atzīst visādus DXus, aliexpres, alibabas, jebajus, jo tur IR LĒTĀK. Pohuj ka mēnesi jāgaida. Tā vietā aizmirstam farneļus, mauzerus, digijekus, rs-electronikas, elfas-distrelekus,tme, vietējās bodītes. Galvenais ir lētāk. Vai sevi vairs nemaz necienam? Klientam var mēģināt iesmērēt lētāk. Vai pašam priekš sevis patīk kaut kas lēts? Personīgi man gribās vislabāko, nevis lētāko. Atvainojiet par žults izgāšanu, bet reizēm tā sauktie elektroniķi, patiesībā kaut kādi šarlatāni-santīmpisēji.
Ja man pat ļoti vajag un/vai gribās, tad maksātu arī vairāk. Nesparotu kāpēc hobijam jāskaita naudu? Naudu jāskaita biznesā nevis hobijā. Izskatās pēc totāla pašcieņas trūkuma.

----------


## sasasa

Nu ko lai tev atbildu. Jā, gribās arī lētāk, jo piemēram, robotiņam ko iepriekš būvēju, beigās biju iztērējis virs 1000eur, lai gan finālā uz viņa esošo komponentu cena bija zem 50eur. Kāpēc? Tikai tāpēc, ka izmēģināju dažādus variantus, kamēr atradu sev piemērotāko, ērtāko, mazāko un ātrāko. Jā, es pērku pārsvarā no eBay, nevis no Baltelektrona vai Lemonas, bet to mēnesi kamēr gaidu man nebūt nav jāsēž bezdarbībā, jo ir jāpabeidz arī iepriekš iesāktais. 
Bet modulītis tiešām interesants. Vai tieši tas, kas man vajadzīgs, šobrīd vēl nezinu. Šajā gadījumā es nebūt neatmetu domu par DWM1000, un ja liksies, ka tas ir tieši tas kas pietrūkst, tad arī noteikti izmēģināšu.
Kāpēc hobijā jāskaita nauda? Laikam tāpēc, lai nebūtu sevi jāierobežo tikai ar kaut ko vienu. Hobijs man nav tikai viens, un kopējās izmaksas visam, ko es gribētu, krietni pārsniedz manus ienākumus, jo daudzas lietas ir dārgas, pie kam daļa no tām nolietojas un ir regulāri jānomaina.    ::

----------


## abergs

> Daži tomēr atzīst visādus DXus, aliexpres, alibabas, jebajus, jo tur IR LĒTĀK. Pohuj ka mēnesi jāgaida. Tā vietā aizmirstam farneļus, mauzerus, digijekus, rs-electronikas, elfas-distrelekus,tme, vietējās bodītes. Galvenais ir lētāk. Vai sevi vairs nemaz necienam? Klientam var mēģināt iesmērēt lētāk. Vai pašam priekš sevis patīk kaut kas lēts? Personīgi man gribās vislabāko, nevis lētāko. Atvainojiet par žults izgāšanu, bet reizēm tā sauktie elektroniķi, patiesībā kaut kādi šarlatāni-santīmpisēji.
> Ja man pat ļoti vajag un/vai gribās, tad maksātu arī vairāk. Nesparotu kāpēc hobijam jāskaita naudu? Naudu jāskaita biznesā nevis hobijā. Izskatās pēc totāla pašcieņas trūkuma.


 Ja JDat dzīvotu kaut kur rietumos, šī brēkāšana būtu saprotama. Bet dzīvojam LV ar LV-algām; hobijam (burtiski: *vaļaspriekam*) var atļauties tērēt tik
cik varam.
var jau nostāties pozā un brīvajā laikā sūkt šnabīti, tam naudas pietiks.
Sorry, offtopiks...

----------


## Jurkins

Vienā no autora abām tēmām bija uzdots jautājums man par SI4432 latenci. Sorry, ka tik ilgi neatbildēju  ::  Tam SI4432 nav 5V tolerantās kājas atšķirībā no nrf. Un bez tam Arduino es ciest nevaru  ::  Bet nu, tā kā mani arī ieinteresēja šīs lietiņas, tad tika savērti divi nano ar SI caur līmeņu čeindžeriem. 

TIMER1 nonstopā skaita tikšķus (tikšķus nevis mikrosekundes!). Vienā mainīgajā (pirmā kolona) ierakstu TCNT1 vērtību pirms padodu SI komandu sūtīt paketi, otrā mainīgajā (otrā kolona) vērtība tiek ierakstīta, kad notiek INT1 pārtraukums no uztvērēja SI GPIO0 kājas - Sync Word Detected. Nu trešā kolona ir šo starpība izdalīta ar 16. 
Uztvērējs:


```

#include "SI4432.h"
#include <util/delay.h>

volatile uint8_t nirq;

ISR(INT1_vect)
{
  
}

int main(void)
{
  uint8_t int1;
  
  PORTD = (1<<PD3);
  PORTB |= (1<<PB1); //NIRQ
  PORTD |= (1<<PD7); DDRD = (1<<PD7); //LED
  _delay_ms(500);
  PORTD &= ~(1<<PD7);
  _delay_ms(2000);
  //EICRA = (1<<ISC10); //INT1 falling edge
  //EIMSK = (1<<INT1);
  
  spi_init();
  
  if(SI4432_reg_read(REG_DEV_TYPE)==0b00001000)
  {
    PORTD |= (1<<PD7);
    _delay_ms(100);
    PORTD &= ~(1<<PD7);
  }
  _delay_ms(500);

  if(SI4432_reg_read(REG_DEV_VERSION)==0b00000110)
  {
    PORTD |= (1<<PD7);
    _delay_ms(100);
    PORTD &= ~(1<<PD7);
  }
  _delay_ms(500);
   
  SI4432_set_interrupts(0x00, INT2_ENABLE_CHIP_READY);
  SI4432_clear_interrupts();        
  SI4432_reg_write(REG_STATE, STATE_SOFTWARE_REGISTER_RESET);
  _delay_ms(10);
  int1 = SI4432_reg_read(REG_INT_STATUS2);
  if(int1 & INT2_ENABLE_CHIP_READY)
  {
    SI4432_init();
    while(1)
    {
      SI4432_reg_write(REG_STATE, STATE_READY_MODE);
      SI4432_set_interrupts(INT1_STATUS_CRC_ERR + INT1_STATUS_VALID_PACKET_REC, 0x00);  
      SI4432_clear_interrupts();
      SI4432_reg_write(REG_STATE, STATE_RX_ON_MANUAL_RECIEVER_MODE);
      while(PINB&(1<<PB1));
      SI4432_reg_write(REG_STATE, STATE_READY_MODE);
      int1 = SI4432_reg_read(REG_INT_STATUS1);
      if(int1 & INT1_STATUS_VALID_PACKET_REC)
      {
          if((SI4432_reg_read(REG_RECEIVED_LENGTH) == 1) && (SI4432_reg_read(REG_FIFO) == 0x55))
          {
            PORTD |= (1<<PD7);
            _delay_ms(100);
            PORTD &= ~(1<<PD7);
          }
      }
      SI4432_reset_rx_fifo();
    }
  }
}
```

 Raidītājs:


```

#include "SI4432.h"
#include <util/delay.h>

volatile uint32_t tim1_ovf_count = 0;
volatile uint16_t startTime_lowWord = 0, endTime_lowWord = 0;

ISR(TIMER1_OVF_vect)
{
  tim1_ovf_count++;
}

ISR(INT1_vect)
{
  endTime_lowWord = TCNT1;
}

int main(void)
{
  uint8_t int1;
  Serial.begin(115200);
  
  TCCR1B = (1<<CS10);
  TIMSK1 = (1<<TOIE1);
  
  PORTD = (1<<PD3);
  PORTB |= (1<<PB1); //NIRQ
  PORTD |= (1<<PD7); DDRD = (1<<PD7); //LED
  _delay_ms(500);
  PORTD &= ~(1<<PD7);
  _delay_ms(2000);
  EICRA = (1<<ISC10)|(1<<ISC10); //INT1 raising edge
  EIMSK = (1<<INT1);
  sei();
  
  spi_init();
  
  if(SI4432_reg_read(REG_DEV_TYPE)==0b00001000)
  {
    PORTD |= (1<<PD7);
    _delay_ms(100);
    PORTD &= ~(1<<PD7);
  }
  _delay_ms(500);

  if(SI4432_reg_read(REG_DEV_VERSION)==0b00000110)
  {
    PORTD |= (1<<PD7);
    _delay_ms(100);
    PORTD &= ~(1<<PD7);
  }
  _delay_ms(500);
  
  SI4432_set_interrupts(0x00, INT2_ENABLE_CHIP_READY);
  SI4432_clear_interrupts();        
 
  SI4432_reg_write(REG_STATE, STATE_SOFTWARE_REGISTER_RESET);
  _delay_ms(10);
  int1 = SI4432_reg_read(REG_INT_STATUS2);
  if(int1 & INT2_ENABLE_CHIP_READY)
  {
    SI4432_init();
    while(1)
    {
      SI4432_reg_write(REG_STATE, STATE_READY_MODE);
      SI4432_reg_write(REG_PKG_LEN, 1); 
      SI4432_reg_write(REG_FIFO, 0x55);
      SI4432_set_interrupts(INT1_STATUS_PACKET_SENT, 0x00);     
      SI4432_clear_interrupts();
      cli();
      startTime_lowWord = TCNT1;
      sei();
      SI4432_reg_write(REG_STATE, STATE_TX_ON_MANUAL_TRANSMIT_MODE); 
      while(PINB&(1<<PB1));
      SI4432_reg_write(REG_STATE, STATE_READY_MODE);
      int1 = SI4432_reg_read(REG_INT_STATUS1);
      if(int1 & INT1_STATUS_PACKET_SENT) PORTD |= (1<<PD7);
      _delay_ms(200);
      PORTD &= ~(1<<PD7);
      _delay_ms(1000);
      Serial.print(startTime_lowWord);
      Serial.print("\t");
      Serial.print(endTime_lowWord);
       Serial.print("\t\t");
      Serial.println((endTime_lowWord - startTime_lowWord)>>4);
      _delay_ms(1000);
    }
  }
}
```

 Sorry, ka nav komentāru. Šis nav rakstīts nopietnai lietošanai. Ja interesē, tad varu pakomentēt.

Esmu gatavs sagaidīt pārmetumus  ::  par kļūdaino realizāciju.

----------


## JDat

> Te kāds apraksts, pēc kura, cik es sapratu, WiFi iekārtas jau pašas sevi sinhronizē. Izskatās, ka pat dzelža līmenī. Visu gan nesapratu no tā raxta.
> https://en.wikipedia.org/wiki/Timing...ation_Function


 Nu vo. Klāt pieli pēdējā brīža "bonus track". Saucās: Kurš meklē, tas atrod. Interesanta fīča. Paliek jautājums: vai no ESP var nolasīt TSF. Tas būtu diezgan inčīgi un noderīgi.

Atgriežoties pie DIY. Palaidu uz propellera savi NTP interpetāciju. 
Dotajā brīdī delta (latence) ir 2800 cikli +/-550 cikli, jeb 350 uS +/- 69 uS. Interesanti ka latence ir tikai divi skaitļi vai nu 2304 vai 3408 cikli. Kpaēc pieminu ciklus? Tāpēc ka MCu clock=80 MHz un ar tādu frekvenci skaita master timer, jeb ciens cikls=0.125 uS
Thau (kavēšana) star klientu un serveri ir: 174250 cikli +/ 350 cikli, jeb 21.78 mS +/- 43 us. Kaut kas manšajos ciparos ļoti nepatīk. Prasās izmēģināt ASM versiju, jo SPIN interpretators varētu būt pārāk lēns, par at visām hardcore optimizācijām. Varbūt arī kaut kuc esmu pielaidis fundamentālu kļūdu.

----------


## JDat

> TIMER1 nonstopā skaita tikšķus (tikšķus nevis mikrosekundes!). Vienā mainīgajā (pirmā kolona) ierakstu TCNT1 vērtību pirms padodu SI komandu sūtīt paketi, otrā mainīgajā (otrā kolona) vērtība tiek ierakstīta, kad notiek INT1 pārtraukums no uztvērēja SI GPIO0 kājas - Sync Word Detected. Nu trešā kolona ir šo starpība izdalīta ar 16. 
> Esmu gatavs sagaidīt pārmetumus  par kļūdaino realizāciju.


 Da pofig visi tie komentāri!

Gribi teikta ka tev ir:
i1) nano uz 16 MHz kvarca/kream. rezonatora
i2) viens tiksķis ir ekvivalents 16 MHz?
i3) Starpība ir ~ +/- 1 uS (mikrosekunde)?
i4)

```
if (i1 && i2 && i3) {eju_atspārdīties();}
```

----------


## Jurkins

Aha, nano uz 16MHz, 16 bitu taimeris skaita bez dalītāja.
Nu tā sanāk, ka +/- 1 us.
Nesapratu, kas ar to "if" domāts, bet tas galīgi nav svarīgi. Notikums Sync Word Detected jau sen ir noticis, vienkārši, pārliecināmies, ka pakete ir 1 baitu gara un tas baits ir 0x55. edit: sapratu, laikam miegs nāk, lēnā pielekšana  :: 

Datareits tam SI gan ir iemests kāut kāds neatceros kāds, vnk paņēmu no citas vietas copy/paste. Rīt paņemšu to viņu Excelgrāmatu un paspēlēšos ar ātrumiem un modulācijām...

----------


## JDat

> Nesapratu, kas ar to "if" domāts, bet tas galīgi nav svarīgi.


 Ja noteikumi i1-i3 izpildās, tad eju atspārīties. Kaspičs savulaik bija ielicis video kā var pats sevi atspādīt, tikai nevaru atrast linku. Šobrīd ļoti noderētu.  ::

----------


## Jurkins

Jā, man lēnā pielekšana bija uz brīdi  :: .
Itin kā šaizi atrast nevaru...

----------


## sasasa

> Nu trešā kolona ir šo starpība izdalīta ar 16.


 Rezultāts iespaidīgs, lai gan nedaudz liekas aizdomīgi, ka tik precīzi 1010/1011.  Tagad nevaru izšķirties vai pasūtīt un mēģināt šos raidītājus vai tomēr izkost to TSF.




> Paliek jautājums: vai no ESP var nolasīt TSF. Tas būtu diezgan inčīgi un noderīgi.


 
Ja nekļūdos, tad šeit 0x3ff21048

----------


## Jurkins

> Rezultāts iespaidīgs, lai gan nedaudz liekas aizdomīgi, ka tik precīzi 1010/1011.


 Nu  jā, ir jau aizdomīgi. Bet nu tās pirmās divas kolonas - skaitītājs  pirms komandas "sūtīt" un saņemot apstiprinājumu no uztvērēja... 
Padomāju, mož tam nano iekš CLKPR ierakstīts kaut kas, un CLKi/o != CLKcpu. Nekā, CLKPR vienas nulles.

----------


## sasasa

> vai no ESP var nolasīt TSF. Tas būtu diezgan inčīgi un noderīgi.


 Izrādās ka tas TSF darbojas tikai AP mode. STA ir bez STF, līdz ar ko nekāda dižā sinhronizācija tur nesanāk. Tas tā teorētiski, bez praktiskiem experimentiem. 
*BET*, vai *JDat* gadījumā neminēja ka darbojas ar *RTL8710*??  Vai tam modulim nav pilns* TSF* abos galos?

----------


## sasasa

> Bet nu tās pirmās divas kolonas - skaitītājs  pirms komandas "sūtīt" un saņemot apstiprinājumu no uztvērēja... 
> .


 Paskatījos tikus un redzot <+-15 no rādījuma uz rādījumu liek domāt, ka tomēr tā arī varētu būt. Interesanti cik tas laiks aizpeld mainoties attālumam starp TxRx
Šobrīd mani iedvesmojusi tā TSF padarīšana. Ja nu tiešām ir tā kā domāju, tad VISPĀR neko nevajag, jo viss jau dzelzī notiek. Bet diez vai viss tik skaisti būs, jo tur arī dažādas nianses.

----------


## JDat

Es Tavā vietā turētu plauktiņā gan vairākus ESP, gan paņemtu ar rezervi arī SiLabus. Tāpat kā Arduino, Teiksim 3 Uno un 3 ProMini. Vairākus FTDI donglus. Tā teik: lai var uzturēt saimniecību. Nekad nevar zināk ko pēkšņi ievajadzēsies. Nav nopietni ja katrai idejai cikls ir vismaz mēnesi garš.

Nē RTL8710 neskatījos. Nav bijusi praktiska vajadzība. Pagaidmā pietiks ja apgūšu ESP. Piemēram: jānotestē attālumi, kuri lielāki par dažiem kilometriem.

----------


## sasasa

Ir jau ir tā "saimniecība" iekrājusies kopš robota laikiem - ESp vien kādi 7+gb, daži Nano, daži Leonardo/MicroPro, Promini, Uno, STM32, visādi BT,  nRF,  visādi sensori, LiPo lādetāji, dc-dc boosteri, draiveri utt.  Citreiz pašam pārsteigumi parokoties pa kastēm  ::   Pagaidām pietrūkst tik ESP ar ārējām antenām, Silabi un RTL.
Ja godīgi ESpkas nedaudz kretinē ar savu nestabilitāti. Vienu brīdi neganti cīnījos ar wdt. Tad atkal pēkšņi kādu dienu neko nevar ierakstīt $^^##&##&, nākošā diena viss kartībā. + vēļ tā noslēpumā turētā dokumentācija, kad daudzas lietas eksperimentāli jāizpēta un jāatrod. Nav stabilitātes sajūta viņas lietojot. Ērti tas ka viena čipā gan procesors gan WiFi.

----------


## sasasa

Pagaidām labākais ko dabūju caur WiFi ir 100us izkliede. Man izstāstīja, tad ESP8266  WiFi darbībā esot pārtraukumu aizliegumi līdz 100us, kas arī aizkavē mana sensora pārtraukumu. Līdz ar to sāku apsvērt ESP8266 lietderību, ja nepieciešama precizitāte mazāka par 100us.

----------


## sasasa

> ... lēnām braucot iekš C++ ...


 Man stingri pieteica neizmantot C++ un izmantot tikai C, lai veiktu darbības, kur nepieciešama precīza laika kontrole. Tas bija saistībā ar pulksteņu laiku sinhronizāciju. Īsti līdz galam tā arī nesapratu to iemeslu, bet ideja bija tāda, ka dēļ C++ var veidoties gari pārtraukumi (interrupts), kas traucē citus procesus. Varbūt kāds var ko sīkāk paskaidrot.
Edited: sorry, nepareizajā sadaļā iepostēju, bet par cik jau ir atbilde, tad nedzēsīšu.

----------


## karloslv

Neredzu nekādu iemeslu nelietot C++. Tehniski tur nekādu garu pārtraukumu nevarētu būt. Sakompilēto kodu var nočekot, objektu failus disasemblējot. Esmu to skatījies, izvērtējot pats šo jautājumu, vai paļauties uz C++ ģenerēto kodu, un neredzu tur nekādu problēmu. Nevajag aizrauties ar gatavo C++ "kārumu" lietošanu, t.i. STL un tamlīdzīgām bibliotēkām, bet vienkārši lietot to, ko C++ kā valoda piedāvā - klases un iespēju attiecīgi organizēt kodu daudz lasāmākā veidā. Ja neizmanto exceptions, tad vispār gan mentāli savā prātā, gan droši vien fiziski varētu jebkuru C++ kodu pārtranslēt uz C kodu, mainās vienkārši pieraksts (un uz stipri vienkāršāku, manuprāt).

----------


## sasasa

> Neredzu nekādu iemeslu nelietot C++. Tehniski tur nekādu garu pārtraukumu nevarētu būt.


 C++ atmiņu izmanto savādāk nekā C, un lidz ar to pats izveido kautkādus pārtraukumus. Lidz ar to, kad svarīgas us, tas rodoties aiztures.Tas no tā cik sapratu.

----------


## JDat

Skarbie vīri kuru vajag nedaudz piešpricē ASM. Tāpat var skatīties ASM source un saprast kas cik daudz apēd. Vēl ir variants izmantot pliku AVR GCC bez Arduino LIBa. Tomēr arī labi uzrakstīt arduino kods nav nekāda bremze.

----------


## sasasa

Tagad nedaudz papētīju - izskatās, ka C++ bēda ir _alloc mem_ izmatošana. Tad, kad precizitāte ir jau mikrosekundēs, tad tur ieviešas pamatīgas kļūdas, bet šobrīd, kamēr man nezdodas "palīst" zem 50us (ar ESP8266), liekas ka mani arī C++ neraucē.
Šobrīd lielākais traucēklis ir garie WiFi pārtraukumi.

----------


## Jurkins

Šad tad ir interesanti palasīt forumos asm vs c vs c++  :: . Mana pieredze programmēšanā ir ... nekāda salīdzinot, bet uzskats ir - jālieto tas instruments, kas vislabāk palīdz konkrētajā situācijā. Un jāiemācās tas pareizi lietot. Bija labs rakstiņš (mirklī nevaru linku atrast) par darbībām ar I/O. Čoms izmantojot C++ vipendronus (no kuriem es 3/4 nesapratu  ::  ... pagaidām) dabūja universālu, ērti pielietojamu koda gabalu, kurš dizassemblējot deva ārā to pašu it kā būtu asmā rakstīts. C++ mani paņēma klases.  Vispār es mēģināju piedabūt Atmel Studio darboties ar arduino. It kā sanāca - simulators strādāja, varēja dizassemlēto kodu paskatīties, bet tā īsti stabili nestrādāja. Tagad met ārā kaut kādu kļūdu, un negribulis meklēt, kaur vaina.

----------


## karloslv

C un C++ atmiņu allocē pilnīgi vienādi - apakšā ir POSIX malloc() izsaukums. Tā ka nejaukt te gaisu ar svētajiem kariem  ::  Laikkritiskos lietojumos nekādu heap un malloc()/new!

----------


## sasasa

Nevaru strīdeties, jo pats visu īsti neizprotu, bet tas no interneta izlasītā,:
_Trustme - writing kernel code in C++ is a BLOODY  STUPID IDEA. The fact is, C++ compilers are not  trustworthy. The whole C++  exception handling  thing is fundamentally  broken. It's _especially_ broken  for kernels. Any compiler or language that  likes to hide things like memory  allocations behind your back just isn't a good choice for a kernel.” However, C++ developers are  still “seduced” by powerful and flexible libraries and  language features that can “bloat”  your code, and we still have to be  aware of “tricks and traps” to  avoid “things like memory  allocations behind your  back”.  And this is  definitely not a new problem when it  comes to embedded  and real-time systems.
_
Arduino Ide jau arī rāda visvisādus brīnumus kompilējot kodu. Citreiz vai vesela lapa ar sarkanu, bet beigās tomēr ielādē tādu kā ir sanācis. Citreiz strādā, citreiz ik pa laikam karas augšā. Nav līdz galam atkļūdots tas ESP8266 pielāgotais variants. Vai arī pavirši uzrakstīts

----------


## JDat

Ak tad ESP nevis AVR...

Vārdu sakot rādi pilnu kodu.

----------


## sasasa

Kods šobrīd amēram tāds, pagaidām vēl bez web servera. Tikai sensoru signālu laiku fikēšana


```


void ICACHE_FLASH_ATTR GetTime() {
  ets_intr_lock();
#ifdef STA
  if (get_time == 0) get_time = get_tsf_station();
#else //AP
  if (get_time == 0) get_time = get_mac_time();
#endif
  ets_intr_unlock();
}
 
void setup() {
  Serial.begin(115200);
  WiFi.setOutputPower(power);
  wifi_set_sleep_type(NONE_SLEEP_T);
#ifdef STA
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) 
#else //AP
  WiFi.softAP(ssid, password);
  while (!Udp.begin(listenPort)) ;
#endif
  pinMode(inPin, INPUT_PULLUP);
  attachInterrupt(inPin, GetTime, FALLING);
 }
 
void loop() {
  if (get_time > 0) { // ... 1. sensora signaala laiks
#ifdef STA
    Udp.beginPacket(sendIP1, sendPort);
    Udp.write(IntToChar(get_time));
    Udp.endPacket();
    for (int i = 0; i < 20; i++) {
      bufChar[i] = '0';
    }
#endif
    delay(200);//button debounce
    get_time = 0;
  }
#ifndef STA
  uint8_t packetSize = Udp.parsePacket();
  if (packetSize) {
    Udp.read(packetBuffer, 64);// ... 2. sensora signaala laiks
  //  Serial.write(packetBuffer, packetSize);
    data[cnt] = charToInt(packetBuffer)- getTime;// laika intervals starp abiem sensoriem
    cnt++;
  }
#endif
}
```

----------


## karloslv

> Nevaru strīdeties, jo pats visu īsti neizprotu, bet tas no interneta izlasītā,:
> _Trustme - writing kernel code in C++ is a BLOODY  STUPID IDEA. The fact is, C++ compilers are not  trustworthy. The whole C++  exception handling  thing is fundamentally  broken. It's _especially_ broken  for kernels. Any compiler or language that  likes to hide things like memory  allocations behind your back just isn't a good choice for a kernel.” However, C++ developers are  still “seduced” by powerful and flexible libraries and  language features that can “bloat”  your code, and we still have to be  aware of “tricks and traps” to  avoid “things like memory  allocations behind your  back”.  And this is  definitely not a new problem when it  comes to embedded  and real-time systems.
> _
> Arduino Ide jau arī rāda visvisādus brīnumus kompilējot kodu. Citreiz vai vesela lapa ar sarkanu, bet beigās tomēr ielādē tādu kā ir sanācis. Citreiz strādā, citreiz ik pa laikam karas augšā. Nav līdz galam atkļūdots tas ESP8266 pielāgotais variants. Vai arī pavirši uzrakstīts


 Drusku citam kontekstam - tas ir a) pietiekami lielām sistēmām ar kerneli un OS, b) patiesībā runa ir par exceptions, par kurām ir pilnīga taisnība, taču tās var gluži vienkārši nelietot un pat kompilatora līmenī atslēgt (un nav nekādas nepieciešamības mazos mikrokontrolieru projektos), c) cilvēks runā par dažādu bibliotēku lietošanu - tas arī ir big no-no, ja nu vienīgi ir labi zināms, kā tā ir uzrakstīta un ka aiz muguras netaisīs lieku atmiņas menedžmentu, bet tas tikpat labi attiecas uz C bibliotēkām. Tas ir jautājums par pašas bibltiotēkas uzticamību, nevis valodu. Jā, viņa komentārs ir vērā ņemams lielām sistēmām ar mikroprocesoriem un kaudzi atmiņas, bet tos uzģenerētos 6 kilobaitus AVR koda gan es pats varu pārskatīt un pārbaudīt, ja nu kas, un līdz šim nekādu grābekļu nav bijis. 

P.S. Exceptions nav "pārtraukumi", bet gan dažādu skaitļošanas kļūdu apstrādes mehānisms. Pārtraukumi ir "interrupts", un tāpēc arī salecos sākumā no apgalvojuma, ka C++ ģenerē pārtraukumus. Pārtraukumi ir pārsvarā hardware lauciņā.

----------

